linux进程调度的时间片问题

weiweishuo

  假设linux的一个时钟滴答是20ms，当前正在执行A进程，A进程在某个时钟滴答的第10ms主动挂起，并触发进程调度模块，紧接着开始执行B进程。我的问题来了：
  在这次非时钟中断触发的进程切换过程中，A进程的time_slice会减1吗？为什么？
  B进程运行10ms之后就会迎来一个时钟中断，那么在这次时钟中断过程里，B进程的time_slice会减1吗？我觉得减也不是，不减也不是。因为B进程仅仅执行了半个时钟节拍啊！
  在下哪儿叙述不清楚的，还望指出，我一定补充说明...恳请高手指点！

weiweishuo

我在论坛上搜到一篇类似帖子：http://bbs.chinaunix.net/thread-2031951-1-1.html
摘录几句：
-------------------------------------------------------------------------------------------------------------------
--------------
可能比较弱智  所以弱问下
就是在时钟中断到来的时候   scheduler_tick()会递减current的时间片
但两个时钟节拍之间可能有多个进程运行过  只递减节拍到来时的当前进程的时间片么？

--------------
不能都递减，因为时间片确实只耗费了一个
对谁都不公平相对就公平了
晚上找找帖子，现在要下线了


--------------
这不存在不公平。既然以tick作为调度的时间单位，那在没消耗到这个最小单位的进程自然不需要记账。


------------
这样对当前进程B记帐可能是不公平的
因为这个tickB可能刚开始运行，而A却运行了这个tick的90％


---------
是的，理论上是存在这种不公平的情况。
但我觉得这只是理论上，因为不管把时间粒度细化到多小，理论上可以找到一个更小的时间粒度来细化，这样不公平的情况会一直存在。
在实现上既然已经选定一个最小单位了，小于这个最小单位的时间的情况就应忽略，那么在这个时间刻度上对大家来说就是公平的。
把HZ从100改到1000可以让时间更精准些、更公平些，但不管改多大都有一个更精准的值
-------------------------------------------------------------------------------------------------------------------

weiweishuo

回复 1# weiweishuo

  一楼里说到最小的时间度量单位是一个时钟节拍，我很无知的问一句，为什么就不能再细分了呢？例如A进程启动的时候可以读一次系统实时钟时间并存储，挂起的时候再读一次实时钟时间，前后之差，就是A进程消耗的处理器时间了，不过这就不是以时钟节拍为单位，而是以毫秒为单位了。但这样至少公平。
   

giant1st

个人觉得 ：
CPU频率，就是CPU的时钟频率，简单说是CPU运算时的工作频率（1秒内发生的同步脉冲数）的简称。单位是Hz。

时间片 也就必然是 时钟滴答的整数倍。

“A进程在某个时钟滴答的第10ms主动挂起”，那他所属的时间片应该都属于他本身的，剩下的10ms应该还是属于进程A。

整个时间片用完，才会执行同等优先级的其他也是SCHED_RR调度策略的进程。


时间片只是用来重新调度相同优先级的进程。

giant1st

weiweishuo 发表于 2012-10-19 06:55
回复 1# weiweishuo

  一楼里说到最小的时间度量单位是一个时钟节拍，我很无知的问一句，为什么就不能再 ...

读一下系统时间 需要好多个 时钟周期的。。。

====
      指令周期（Instruction Cycle）：取出并执行一条指令的时间。
　　总线周期（BUS Cycle）：也就是一个访存储器或I/O端口操作所用的时间。
　　时钟周期（Clock Cycle）：处理操作的最基本单位。(CPU的主频的倒数，也称T状态)
　　指令周期、总线周期和时钟周期之间的关系：一个指令周期由若干个总线周期组成，而一个总线周期时间又包含有若干个时钟周期。

embeddedlwp

貌似内核中已经没有时间片的概念了吧？

chinawrj

Linux的内核设计与实现这本书中说过，tick到来的时候直接把时间记到了current的thread上。的确存在你说的那种不公平。就是一次tick之间，线程切换了很多次，那么这段tick的时间只会记到tick到来记账时的thread头上。具体参见内核源代码或者Linux内核设计与实现的那本书的11章。
不过话说回来了，内核就是靠tick来计时记账的，你还要切开tick的话，那只能是为难内核了。哈哈

blake326

现在都是hrtimer定时器模拟以前的tick的。现在HZ一般都是100，就是说1秒钟产生100次hrtimer中断，处理函数是tick_sched_timer里面就是以前tick做的工作，更新系统时间（cpu0做），更新cpu使用信息（同以前一样记在当前进程上，然仍是不公平的），raise timer软中断，tick调度（同以前tick不同时空操作了）。

namewr

貌似这个是没办法回避的问题。时间的粒度不可能比执行几条指令的时间更小。
这个记账的问题在Windows中也是存在的。
唯一能够做的只有每次时间中断都更新统计数据。这样可以使得不公平分配的时间平均值为时间中断时间的一半。

linuxhunter

1、linux内核除了使用SCHED_RR的实时调度器还在使用时间片的概念，SCHED_FIFO实时调度以及非实时调度都不再使用时间片的概念，非实时进程调度采用虚拟时钟的概念；
2、当进程A主动挂起且调用schedule()进行主动调度时，在schedule()函数中会依次执行当前进程所在调度器类的put_prev_task()、pick_next_task()以及context_switch()。其中put_prev_task()对当前进程的物理运行时间、虚拟运行时间、CFS运行队列min_vruntime和curr的更新以及将当前进程重新插入到CFS红黑树中。对当前进程物理运行时间和虚拟运行时间进行更新的函数是update_curr()。

所以，在进程被调度出CPU之前对被调度出的进程进行了运行时间的统计。当进程B换入后，schedule_tick()照常会更新进程B的物理／虚拟运行时间。