关于linux中进程间切换的最小时间间隔
本帖最后由 cwang_sh 于 2014-08-12 15:14 编辑大家好！
我想要做的是，将多个进程亲合到一个core上，并且使得他们之间公平地共享该核。
我目前的做法是使用round robin方式，让操作系统的scheduling policy来调度这些进程。在linux内核版本3.9以后，有一个文件/proc/sys/kernle/sched_rr_timeslice_ms用来指示round robin调度进程的间隔，这个间隔默认是100ms。假设有10个进程共享该core，并且每个进程通过sched_setscheduler将其设置成SCHED_RR，这样，在一秒钟内，每个进程将被轮询一次。
我的问题是：
1）我希望这个进程调度间隔是100微妙，即在1毫秒内，每个进程将被轮询一次。但是/proc/sys/kernle/sched_rr_timeslice_ms的数值不能被设置成小于1毫秒，否则就报错。我想确认，是否linux无法支持小于100ms间隔的进程调度？
2）不知道是否有人了解 windriver linux，它是windriver公司经过内核修改后的版本，主要用于嵌入式系统，它的进程调度的最小间隔是多少？
3）如果通过mutex机制，是否可以实现小于1ms的进程调度间隔？这种方法不是利用操作系统的调度策略，而是通过用户进程/程序的设计，当运行时间超过了100微妙后主动释放锁，而其他进程中的某个会获得锁。这个思路是否正确？
4）如果我把这10个进程变为一个进程的10个线程，有什么方法可以实现10个线程间的切换? 切换周期也要小于1ms
5）另外，set_scheduler()函数是不是只能使用于进程，而非线程？
万分感谢您的回复。
cwang_sh 个人理解，对于内核自己来说，调度频率主要取决于时钟中断的频率，默认是1000HZ，所以调度的精度通常为1ms。
要提高调度频率，看似有两种方法：
1、提升HZ，个人觉得提得太高，会系统系统会很大，估计会有问题(没实际测试过~)
2、在被调度的进程中，自己控制运行时间，主动发起调度，但这个非常困难了，除非是极其简单的任务。定时器在此时都已经不起作用了，因为依赖于中断。
总体来说，Linux是非实时系统，即使打上RT补丁，其实时性也难以得到准确的保证，对实时性如此高要求，Linux估计比较难。。。。。 我个人猜测，linux不希望进程之间频繁切换，因为进程切换时，会有context switch overead的，这个开销通常是100us左右，反复进行进程间切换，浪费了CPU 时间。
但我现在希望它100微妙切换一次，因为我做的是信号处理，对实时性能要求高。
Windriver 对linux实时性做了很多优化，但不知道是否对进程调度间隔也做了调整（网上查不到相关信息）。这个调度间隔，是实时系统必须很好解决的一个问题。 Linux很难做到1Hz以下的调度，就算你把调度开销置之不顾，把参数给改了。系统的抖动也是非常大的。不可用。业界对Linux做了很多时实化的方案，有开源的，原商业的。你可以看看。 完全让线程在小于一个时间内在wrlinux上应该做不到。
觉得楼主就是尽量避免业务线程被过多打断，
可以让这些业务线程绑到一个特定核上，并且尽量避免控制线程飘到此核，
尽量提高业务线程优先级，FIFO属性，通过用nanosleep()来做高精度的主动睡眠。百微秒级别是可以的。
需要内核config开启hrtimer。 谢谢各位的解答。
似乎5楼的这个主动睡眠机制比mutex要好，毕竟检测mutex的lock和unlock的时间间隔也不清楚是多少，即操作系统的调度器各多久去探测一下这个Mutex是否已经解锁。 好像还有些问题，如果某个进程通过睡眠，主动放弃了CPU，那么下一个获得CPU的进程是哪个？这完全取决于操作系统的调度了吧。我希望这10个进程被严格地按照某种顺序依次被执行。 cwang_sh 发表于 2014-08-13 08:57 static/image/common/back.gif
好像还有些问题，如果某个进程通过睡眠，主动放弃了CPU，那么下一个获得CPU的进程是哪个？这完全取决于操作 ...
那就需要你自己控制了，可以控制高精度定时器的到期顺序？ 这个好像难度挺大啊，因为我的应用程序很复杂，而且每次运行的时间是依据负载的变化而变化的 commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri Jan 25 21:08:29 2008 +0100
sched: high-res preemption tick
Use HR-timers (when available) to deliver an accurate preemption tick.
The regular scheduler tick that runs at 1/HZ can be too coarse when nice
level are used. The fairness system will still keep the cpu utilisation 'fair'
by then delaying the task that got an excessive amount of CPU time but try to
minimize this by delivering preemption points spot-on.
The average frequency of this extra interrupt is sched_latency / nr_latency.
Which need not be higher than 1/HZ, its just that the distribution within the
sched_latency period is important.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
页:
[1]