lg0812 发表于 2006-6-10 22:27:10

Magic 2.0 采用的内核默认是否使用抢占式进程调度?

在安装ML2.0时抢占式功能是否被开启?
请问如何关掉??

lg0812 发表于 2006-6-10 23:00:28

没有人能告诉我吗????

dogking 发表于 2006-6-10 23:04:16

linux好像都是抢占式吧。
呵呵,英格兰靠巴拉圭的一个乌龙胜了~~~呵呵

haulm 发表于 2006-6-10 23:38:12

我在书上看的:2.6内核是抢占式的,而2.4内核不是抢占式。

lg0812 发表于 2006-6-11 11:54:16

哦,知道了。感谢各位!!!

KDE 发表于 2006-6-12 01:36:10

magic 2.0 采用的内核默认不使用抢占式进程调度,而是采用了平均配置资源的 cfq 进程调度,因为 2.6 kernel 的抢占式进程调度还不理想,开启大型程序会导致正在运行中的多媒体软件播放卡壳。除非必要,比如开启对系统资源独占要求极高的 midi 创作软件支持的情况,否则不要采用抢占式进程调度。

jiangtao9999 发表于 2006-6-12 21:43:11

建议官方内核 + ck 补丁~~

wjfree 发表于 2006-6-12 22:30:50

magic 2.0 采用的内核默认不使用抢占式进程调度,而是采用了平均配置资源的 cfq 进程调度,因为 2.6 kernel 的抢占式进程调度还不理想,开启大型程序会导致正在运行中的多媒体软件播放卡壳。除非必要,比如开启对系统资源独占要求极高的 midi 创作软件支持的情况,否则不要采用抢占式进程调度。
即使这样在播放音乐的时候开启一些程序的时候声音还是会有断续,特别是打开大量程序的时候
在Win下这种情况极少发生
linux下可以改进吗?

sunmoon1997 发表于 2006-6-12 22:32:57

magic 2.0 采用的内核默认不使用抢占式进程调度,而是采用了平均配置资源的 cfq 进程调度,因为 2.6 kernel 的抢占式进程调度还不理想,开启大型程序会导致正在运行中的多媒体软件播放卡壳。除非必要,比如开启对系统资源独占要求极高的 midi 创作软件支持的情况,否则不要采用抢占式进程调度。
不要把进程调度和 IO 调度搞混了。

lg0812 发表于 2006-6-13 07:55:24

好象是一个比较复杂的问题!

KanKer 发表于 2006-6-13 09:44:27

ML 用的也算是抢先式调度,看看说明吧:
Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)

This option reduces the latency of the kernel by adding more
"explicit preemption points" to the kernel code. These new
preemption points have been selected to reduce the maximum
latency of rescheduling, providing faster application reactions,
at the cost of slighly lower throughput.

This allows reaction to interactive events by allowing a
low priority process to voluntarily preempt itself even if it
is in kernel mode executing a system call. This allows
applications to run more 'smoothly' even when the system is
under load.

Select this if you are building a kernel for a desktop system.

老的 Preemptible Kernel,在我的测试中经常会出现因抢先而导致系统僵死状态,故改用 Voluntary Kernel Preemption。这两种的优劣比较也可以在网上查到。

wall_john 发表于 2006-6-13 12:28:49

来帮KanKer补充以下。

LINUX内核有两种抢占模式。
User Preemption 和 Kernel Preemption

User Preemption 出现在:
1 When returning to user-space from a system call
2 When returning to user-space from an interrupt handler
这两个情况都会重置need_resched变量,从而导致重新调度。
这个好像2.4中就有了。

Kernel Preemption
In the 2.6 kernel,the Linux kernel became preemptive: It
is now possible to preempt a task at any point,so long as
the kernel is in a state in which it is safe to reschedule.
就是说,2.6之前的内核,程序调用进入内核(内核态)以后是无
法重新调度的(不可抢占),而2.6内核在以下情况可以重新调度
(可抢占):
1 When an interrupt handler exits, before returning to kernel
-space
2 When kernel code becomes preemptible again
3 If a task in the kernel explicitly calls schedule()
3 If a task in the kernel blocks(which results in a call to
schedule.

第2个是内核中设置了一些判断点,当发现进程的preempt_count为
0时,说明该进程没有控制可抢占的资源,内核达到可重新调度点,
然后重新调用schedule来调度其它优先进程。

大家注意以下,在linux中没有所谓thread的实体,linux中thread
也是通过process实现的,linux中线程只是一个特殊的进程。

demonlj 发表于 2006-6-13 12:42:27

好久不见john,又一个不错的解释

KDE 发表于 2006-6-13 19:04:22

magic 2.0 采用的内核默认不使用抢占式进程调度,而是采用了平均配置资源的 cfq 进程调度,因为 2.6 kernel 的抢占式进程调度还不理想,开启大型程序会导致正在运行中的多媒体软件播放卡壳。除非必要,比如开启对系统资源独占要求极高的 midi 创作软件支持的情况,否则不要采用抢占式进程调度。
不要把进程调度和 IO 调度搞混了。
sorry,是我记错了

lg0812 发表于 2006-6-15 11:12:10

实在是复杂,搞不懂!!!
页: [1] 2
查看完整版本: Magic 2.0 采用的内核默认是否使用抢占式进程调度?