Chinaunix

标题: 怎么有三种抢占选择？ [打印本页]

作者: xparmenides 时间: 2012-04-09 15:30
标题: 怎么有三种抢占选择？

配置内核在选择抢占方式时发现有三个选项：

No forced preemption (server)
voluntary kernel preemption (desktop)
preemptible kernel (low-latency desktop)

这三项有何区别？

作者: 瀚海书香 时间: 2012-04-10 11:59
本帖最后由瀚海书香于 2012-04-10 12:36 编辑

回复 1# xparmenides
说白了就是允许抢占的时机点的不同。
PREEMPT_NONE 禁止优先级抢占
PREEMPT_VOLUNTARY 增加自愿抢占的时机，但是禁止内核态抢占
PREEMPT 允许内核态抢占

6config PREEMPT_NONE
7 bool "No Forced Preemption (Server)"
8 help
9 This is the traditional Linux preemption model, geared towards
10 throughput. It will still provide good latencies most of the
11 time, but there are no guarantees and occasional longer delays
12 are possible.
13
14 Select this option if you are building a kernel for a server or
15 scientific/computation system, or if you want to maximize the
16 raw processing power of the kernel, irrespective of scheduling
17 latencies.
18
19config PREEMPT_VOLUNTARY
20 bool "Voluntary Kernel Preemption (Desktop)"
21 help
22 This option reduces the latency of the kernel by adding more
23 "explicit preemption points" to the kernel code. These new
24 preemption points have been selected to reduce the maximum
25 latency of rescheduling, providing faster application reactions,
26 at the cost of slightly lower throughput.
27
28 This allows reaction to interactive events by allowing a
29 low priority process to voluntarily preempt itself even if it
30 is in kernel mode executing a system call. This allows
31 applications to run more 'smoothly' even when the system is
32 under load.
33
34 Select this if you are building a kernel for a desktop system.
35
36config PREEMPT
37 bool "Preemptible Kernel (Low-Latency Desktop)"
38 select PREEMPT_COUNT
39 help
40 This option reduces the latency of the kernel by making
41 all kernel code (that is not executing in a critical section)
42 preemptible. This allows reaction to interactive events by
43 permitting a low priority process to be preempted involuntarily
44 even if it is in kernel mode executing a system call and would
45 otherwise not be about to reach a natural preemption point.
46 This allows applications to run more 'smoothly' even when the
47 system is under load, at the cost of slightly lower throughput
48 and a slight runtime overhead to kernel code.
49
50 Select this if you are building a kernel for a desktop or
51 embedded system with latency requirements in the milliseconds
52 range.
53

作者: amarant 时间: 2012-04-13 17:07
配置的时候按H可以看说明，也可以像LS一样直接读Kconfig。再搞不明白就去看Makefile里面需要读的源码吧。

作者: tempname2 时间: 2012-04-15 12:44
本帖最后由 tempname2 于 2012-04-15 14:39 编辑

真没注意中间那种情况，搜索一下，还是有历史的。2.6的早期PREEMPT_VOLUNTARY和PREEMPT似乎不是互斥的，而且可以动态的独立开启关闭，排列组合。

如果选中了，就是传统非内核抢占，加上新增might_sleep作为主动调度点。显式用sched调度那因为没别的事做了，而用might_sleep调度时则有是事可做但调度无害，但为了低lantency，还是调度了。

==========

理解有偏差，might_sleep不仅是睡眠无害，而且是极有可能睡眠。这个东西的初衷应该是检测在中断上下文中调用某些函数，而非(如我之前所想)暗示可以被抢占。

作者: mordorwww 时间: 2014-01-24 14:16
怎么自愿抢占，进程不会自己加自愿抢占，是不是基于时间片？

作者: humjb_1983 时间: 2014-01-24 15:36

mordorwww 发表于 2014-01-24 14:16
怎么自愿抢占，进程不会自己加自愿抢占，是不是基于时间片？

这个应该只是一个概念而已，本质上只是增加了调度时机。

作者: mordorwww 时间: 2014-01-24 16:04

humjb_1983 发表于 2014-01-24 15:36
这个应该只是一个概念而已，本质上只是增加了调度时机。

应该不仅仅是增加了调度时机。如果三次调度间隔为1ms和10分钟，虽然多了最后一次调度，但是间隔太长

作者: humjb_1983 时间: 2014-01-24 16:14

mordorwww 发表于 2014-01-24 16:04
应该不仅仅是增加了调度时机。如果三次调度间隔为1ms和10分钟，虽然多了最后一次调度，但是间隔太长

还是没怎么看明白，呵呵，调度不一定是在时钟中断来的时候发生的，普通的中断返回也有调度点的，当然还有其他的调度点，比如系统调用返回，wake_up进程等。

作者: mordorwww 时间: 2014-01-24 16:28

humjb_1983 发表于 2014-01-24 16:14
还是没怎么看明白，呵呵，调度不一定是在时钟中断来的时候发生的，普通的中断返回也有调度点的，当然还有 ...

我是说内核线程怎么办？只有时钟中断是可靠的啊，其它的中断和系统调用返回啥时有，根本就不确定啊，也可能很长时间没有啊

作者: humjb_1983 时间: 2014-01-24 16:35

mordorwww 发表于 2014-01-24 16:28
我是说内核线程怎么办？只有时钟中断是可靠的啊，其它的中断和系统调用返回啥时有，根本就不确定啊， ...

是的，时钟中断(在没有nohz)的情况下是固定的，默认1ms一次，如果配置了抢占，那至少每次时钟中断的时候调度，这个应该是最高待遇了~

作者: mordorwww 时间: 2014-01-24 16:38

humjb_1983 发表于 2014-01-24 16:35
是的，时钟中断(在没有nohz)的情况下是固定的，默认1ms一次，如果配置了抢占，那至少每次时钟中断的时候调 ...

所以我想所谓的自愿抢占是不是在时钟中断里检查有没有内核线程或者是系统调用运行的时间太长，太长了就schedule？
不然的话，难道还让进程线程自己做这个事情？

作者: humjb_1983 时间: 2014-01-24 16:54

mordorwww 发表于 2014-01-24 16:38
所以我想所谓的自愿抢占是不是在时钟中断里检查有没有内核线程或者是系统调用运行的时间太长，太长了 ...

其他地方设置NEED_RESCHED标记，在中断返回的时候判断该标记，如果有就调度。

作者: mordorwww 时间: 2014-01-24 17:01

humjb_1983 发表于 2014-01-24 16:54
其他地方设置NEED_RESCHED标记，在中断返回的时候判断该标记，如果有就调度。

那你这和强制抢占有什么区别

作者: humjb_1983 时间: 2014-01-24 18:53

mordorwww 发表于 2014-01-24 17:01
那你这和强制抢占有什么区别

确实没搞明白你的疑问到底是啥？呵呵

作者: mordorwww 时间: 2014-01-25 09:43

humjb_1983 发表于 2014-01-24 18:53
确实没搞明白你的疑问到底是啥？呵呵

Voluntary Kernel Preemption和Preemptible Kernel 区别

作者: humjb_1983 时间: 2014-01-26 08:22

mordorwww 发表于 2014-01-25 09:43
Voluntary Kernel Preemption和Preemptible Kernel 区别

具体没有研究过，但是应该如之前大家所说，差别仅在于调度的时机多少而已，Preemptible Kernel的调度点肯定要多一些。

作者: crspo 时间: 2014-01-26 15:20
see might_resched():

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

作者: humjb_1983 时间: 2014-01-27 16:55
还是代码最有说服力了。

作者: mordorwww 时间: 2014-02-02 10:36

crspo 发表于 2014-01-26 15:20
see might_resched():

#ifdef CONFIG_PREEMPT_VOLUNTARY

这个我以前也看过

只是这样的话，内核被抢占的活得进程自己干了

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