Chinaunix

标题: CONFIG_PREEMPT和CONFIG_PREEMPT_VOLUNTARY有什么区别 [打印本页]

作者: mordorwww 时间: 2013-03-28 14:01
标题: CONFIG_PREEMPT和CONFIG_PREEMPT_VOLUNTARY有什么区别
本帖最后由 mordorwww 于 2013-03-28 14:02 编辑

这儿有个帖子 http://bbs.chinaunix.net/thread-2075934-1-1.html

看了文档的描述，还是不清楚

这两种都是内核可抢占么，有什么区别？
抢占就是被强迫抢占的吧，怎么还有个自愿抢占？费解

作者: 瀚海书香 时间: 2013-03-29 07:23
回复 1# mordorwww
自愿抢占的实时性更好一些，会在一些地方插入主动调度的代码。一般服务器配置config_preempt;个人pc为了实时性可以配置config_preempt_voluntary。

作者: mordorwww 时间: 2013-03-29 14:28

瀚海书香发表于 2013-03-29 07:23
回复 1# mordorwww
自愿抢占的实时性更好一些，会在一些地方插入主动调度的代码。一般服务器配置config_p ...

照你这个说法，CONFIG_PREEMPT_VOLUNTARY 仅仅只是内核代码主动调用schedule切出去，不会有内核代码执行中被中断/软中断打断而切出去的?

作者: chishanmingshen 时间: 2013-03-29 14:34
回复 3# mordorwww

#ifdef CONFIG_PREEMPT_VOLUNTARY
extern int _cond_resched(void);
# define might_resched() _cond_resched()
#else
# define might_resched() do { } while (0)
#endif

内核在一些耗时的操作中主动释放cpu，降低时延。

作者: 瀚海书香 时间: 2013-03-29 17:27
回复 3# mordorwww

CONFIG_PREEMPT_VOLUNTARY 仅仅只是内核代码主动调用schedule切出去，不会有内核代码执行中被中断/软中断打断而切出去的?

是除了被打断之外，还会主动要求调度

作者: mordorwww 时间: 2013-03-30 22:59
从我测试的结果看，内核配置成自愿抢占是不会被抢占的

作者: mordorwww 时间: 2013-03-30 23:01
_cond_resched
这个自愿调度是必选的吧，不是可配的

作者: mordorwww 时间: 2013-03-30 23:13
The Linux 2.6 configuration option CONFIG_PREEMPT_VOLUNTARY introduces checks to the most common causes of long latencies, so that the kernel can voluntarily yield control to a higher priority task waiting to execute. This can be helpful, but while it reduces the occurences of long latencies (hundreds of milliseconds to potentially seconds or more), it does not eliminate them. However unlike CONFIG_PREEMPT (discussed below), CONFIG_PREEMPT_VOLUNTARY has a much lower impact on the overall throughput of the system. (As always, there is a classical tradeoff between throughput --- the overall efficiency of the system --- and latency. With the faster CPU's of modern-day systems, it often makes sense to trade off throughput for lower latencies, but server class systems that do not need minimum latency guarantees may very well choose to use either CONFIG_PREEMPT_VOLUNTARY, or to stick with the traditional non-preemptible kernel design.)
The 2.6 Linux kernel has an additional configuration option, CONFIG_PREEMPT, which causes all kernel code outside of spinlock-protected regions and interrupt handlers to be eligible for non-voluntary preemption by higher priority kernel threads. With this option, worst case latency drops to (around) single digit milliseconds, although some device drivers can have interrupt handlers that will introduce latency much worse than that. If a real-time Linux application requires latencies smaller than single-digit milliseconds, use of the CONFIG_PREEMPT_RT patch is highly recommended.

作者: mordorwww 时间: 2013-03-30 23:22
Linux: Voluntary Kernel Preemption
Submitted by Jeremy
on July 10, 2004 - 8:45am
Linux news
In response to a recent discussion on the lkml, Ingo Molnar [interview] posted a patch that introduces "voluntary kernel preemption" into the Linux 2.6 kernel. Ingo explains the problem that he is working to address:

"As most of you are probably aware of it, there have been complaints on [the] lkml that the 2.6 kernel is not suitable for serious audio work due to high scheduling latencies (e.g. the Jackit people complained). I took a look at latencies and indeed 2.6.7 is pretty bad - latencies up to 50 msec (!) can be easily triggered using common workloads, on fast 2GHz+ x86 system - even when using the fully preemptible kernel!"

Ingo explains that voluntary preemption provides latencies equal to what was possible in 2.4 with the low latency patches, aiming for no latency greater than 1 millisecond, however accomplished in a much different way:

"Unlike the lowlatency patches, this patch doesn't add a lot of new scheduling points to the source code, it rather reuses a rich but currently inactive set of scheduling points that already exist in the 2.6 tree: the might_sleep() debugging checks. Any code point that does might_sleep() is in fact ready to sleep at that point. So the patch activates these debugging checks to be scheduling points. This reduces complexity and impact quite significantly."

From: Ingo Molnar [email blocked] To: linux-kernel Subject: [announce] [patch] Voluntary Kernel Preemption Patch Date: Fri, 9 Jul 2004 20:26:38 +0200 as most of you are probably aware of it, there have been complaints on lkml that the 2.6 kernel is not suitable for serious audio work due to high scheduling latencies (e.g. the Jackit people complained). I took a look at latencies and indeed 2.6.7 is pretty bad - latencies up to 50 msec (!) can be easily triggered using common workloads, on fast 2GHz+ x86 system - even when using the fully preemptible kernel! to solve this problem, Arjan van de Ven and I went over various kernel functions to determine their preemptability and we re-created from scratch a patch that is equivalent in performance to the 2.4 lowlatency patches but is different in design, impact and approach: http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H2 (Note to kernel patch reviewers: the split voluntary_resched type of APIs, the feature #ifdefs and runtime flags are temporary and were only introduced to enable a easy benchmarking/comparisons. I'll split this up into small pieces once there's testing feedback and actual audio users had their say!) unlike the lowlatency patches, this patch doesn't add a lot of new scheduling points to the source code, it rather reuses a rich but currently inactive set of scheduling points that already exist in the 2.6 tree: the might_sleep() debugging checks. Any code point that does might_sleep() is in fact ready to sleep at that point. So the patch activates these debugging checks to be scheduling points. This reduces complexity and impact quite significantly. but even using these (over one hundred) might_sleep() points there were still a number of latency sources in the kernel - we identified and fixed them by hand, either via additional might_sleep() checks, or via explicit rescheduling points. Sometimes lock-break was necessary as well. as a practical goal, this patch aims to fix all latency sources that generate higher than ~1 msec latencies. We'd love to learn about workloads that still cause audio skipping even with this patch applied, but i've been unable to generate any load that creates higher than 1msec latencies. (not counting driver initialization routines.) this patch is also more configurable than the 2.4 lowlatency patches were: there's a .config option to enable voluntary preemption, and there are runtime /proc/sys knobs and boot-time flags to turn voluntary preemption (CONFIG_VOLUNTARY_PREEMPT) and kernel preemption (CONFIG_PREEMPT) on/off: # turn on/off voluntary preemption (if CONFIG_VOLUNTARY_PREEMPT) echo 1 > /proc/sys/kernel/volun

作者: mordorwww 时间: 2013-04-21 20:19
The Linux 2.6 configuration option CONFIG_PREEMPT_VOLUNTARY introduces checks to the most common causes of long latencies, so that the kernel can voluntarily yield control to a higher priority task waiting to execute. This can be helpful, but while it reduces the occurences of long latencies (hundreds of milliseconds to potentially seconds or more), it does not eliminate them. However unlike CONFIG_PREEMPT (discussed below), CONFIG_PREEMPT_VOLUNTARY has a much lower impact on the overall throughput of the system. (As always, there is a classical tradeoff between throughput --- the overall efficiency of the system --- and latency. With the faster CPU's of modern-day systems, it often makes sense to trade off throughput for lower latencies, but server class systems that do not need minimum latency guarantees may very well choose to use either CONFIG_PREEMPT_VOLUNTARY, or to stick with the traditional non-preemptible kernel design.)
The 2.6 Linux kernel has an additional configuration option, CONFIG_PREEMPT, which causes all kernel code outside of spinlock-protected regions and interrupt handlers to be eligible for non-voluntary preemption by higher priority kernel threads. With this option, worst case latency drops to (around) single digit milliseconds, although some device drivers can have interrupt handlers that will introduce latency much worse than that. If a real-time Linux application requires latencies smaller than single-digit milliseconds, use of the CONFIG_PREEMPT_RT patch is highly recommended.

作者: junnyg 时间: 2013-04-21 20:50
本帖最后由 junnyg 于 2013-04-21 21:03 编辑

回复 1# mordorwww
内核抢占开关三个选项：
1. PREEMPT_NONE---------CONFIG_PREEMPT和CONFIG_PREEMPT_VOLUNTARY都不会设置，表示在内核态既不会被抢占，调might_resched()函数也不会主动切换
2. Low latency desktop----只配置CONFIG_PREEMPT_VOLUNTARY,might_resched()函数生效，内核态依然不会被抢占
3. PREEMPT------------------CONFIG_PREEMPT和CONFIG_PREEMPT_VOLUNTARY同时生效，在中断返回内核态时会检查TIF_NEEDRESCHED标志，如果需要调度，则会调schedule，内核态被抢占

作者: mordorwww 时间: 2013-04-22 07:30

junnyg 发表于 2013-04-21 20:50
回复 1# mordorwww
内核抢占开关三个选项：
1. PREEMPT_NONE---------CONFIG_PREEMPT和CONFIG_PREEMPT_V ...

恩

和我想的挺像

只是might_resched是干嘛的，内核中已经有con_schedule了

作者: xia45399 时间: 2016-03-17 12:35

mordorwww 发表于 2013-03-29 14:28
照你这个说法，CONFIG_PREEMPT_VOLUNTARY 仅仅只是内核代码主动调用schedule切出去，不会有内核代码执 ...

我不能给你发消息，只能从这回复你了，我想测一下内核的抢占时间，在preempt_schedule()函数里加了变量，确实想你说的一直没被执行，有什么办法测试吗

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)