Linux O(n)调度器
Posted Loopers
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Linux O(n)调度器相关的知识,希望对你有一定的参考价值。
前面我们学习了调度器的设计需要关注的几个点,在这里复习下:
- 吞吐量(对应的是CPU消耗型进程)
- 响应速度(对应的是IO消耗型进程)
- 公平性,确保每个进程都可以有机会运行到
- 移动设备的功耗
Linux中调度器的设计,引入的概念
- 普通进程和实时进程使用优先级区分,0-99表示实时进程,100-139表示普通进程
- 实时进程采用两种调度策略SCHED_RR或者SCHED_FIFO
- 普通进程采用nice值进行动态调整普通进程的优先级
- 经常睡眠的进程尝试增大下优先级,经常长占CPU的适当减少优先级
本节我们先来学习Linux早期的调度算法的设计,先从最早的调度器算法开始,此调度器时间复杂度是O(n),所以也可以称为O(n)调度算法。我们选择的内核版本是linux-2.4.19。
O(n)调度器的实现原理
O(n)代表的是寻找一个合适的进程的时间复杂度。调度器定义了个runqueue的运行队列,将进程的状态变为Running的都会添加到此运行队列中,当然了不管是实时进程,还是普通进程都会添加到这个运行队列中。当需要从运行队列中需要一个合适的进程运行时,则就需要从队列的头遍历到尾部,所以说寻找一个合适进程的时间复杂度是O(n),当运行队列中的进程数目逐渐增大,则调度器的效率就会出现明显的下降。
运行队列中的进程是没有次序的,实时进程和普通进程是杂乱无章的在里面排序的。当需要调度器选择下一个进程的时候,则就需要从头遍历,比较每个进程的优先级,优先级高的先运行。当然了只有当实时进程运行完毕才可能轮到普通进程运行的。
struct task_struct结构
struct task_struct
long counter;
long nice;
unsigned long policy;
int processor;
unsigned long cpus_runnable, cpus_allowed;
- counter代表的是进程的时间片,就是进程在一个调度周期中可与运行的时间。
- nice代表这个进程的静态优先级。通过宏NICE_TO_TICKS,可以将对应的nice值转化为对应的时间片,存储在counter中
- policy就是进程的调度策略,实时进程采用的是SCHED_RR或者SCHED_FIFO。普通进程采用的是SCHED_OTHER
- SCHED_RR:同等优先级采用轮转的方式,不同优先级还是高优先级先调度
- SCHED_FIFO:同等优先级采用先来后到的次序,就是先调度的进程如果没运行完毕,后面的只能排队。不同优先级还是高优先级的优先。如果高优先级的实时进程没运行完,低优先级的也是不能运行的。
- pocessor: 代表当前进程运行在那个处理器上,会在SMP系统中使用
- cpu_allowed:代表当前进程允许在那些CPU上可以运行。
时间片的计算
O(n)调度器采用的是TICK的方式,根据对应进程的nice值来计算对应的时间片的。
#if HZ < 200
#define TICK_SCALE(x) ((x) >> 2)
#elif HZ < 400
#define TICK_SCALE(x) ((x) >> 1)
#elif HZ < 800
#define TICK_SCALE(x) (x)
#elif HZ < 1600
#define TICK_SCALE(x) ((x) << 1)
#else
#define TICK_SCALE(x) ((x) << 2)
#endif
#define NICE_TO_TICKS(nice) (TICK_SCALE(20-(nice))+1)
nice值的取值范围是-20 ~ +19, 取值越小优先级越高。进程的默认nice值是0,则进程默认的静态优先级就等于20.
我们以100HZ来计算下,各个nice值下一个进程可以占用的时间片。
nice值 | -20 | -10 | 0 | +10 | +19 |
100HZ | 11tick | 8tick | 6tick | 3tick | 1tick |
时间片 | 110ms | 80ms | 60ms | 30ms | 10ms |
当然了这些时间片是根据静态的优先级计算出来的,当进程运行起来后会对睡眠的进程做一个补偿的。
O(n)调度器算法核心
从运行队列中选择一个优先级最高的进程
list_for_each(tmp, &runqueue_head)
p = list_entry(tmp, struct task_struct, run_list);
if (can_schedule(p, this_cpu))
int weight = goodness(p, this_cpu, prev->active_mm);
if (weight > c)
c = weight, next = p;
就是从runqueue运行队列中逐个遍历,can_schedule函数用于判断当前进程是否可以在this_cpu上运行,是针对SMP系统的。
最主要的核心算法是在goodness函数中找出优先级最高的一个进程。
static inline int goodness(struct task_struct * p, int this_cpu, struct mm_struct *this_mm)
/*
* Non-RT process - normal case first.
*/
if (p->policy == SCHED_OTHER)
weight = p->counter;
if (!weight)
goto out;
#ifdef CONFIG_SMP
/* Give a largish advantage to the same processor... */
/* (this is equivalent to penalizing other processors) */
if (p->processor == this_cpu)
weight += PROC_CHANGE_PENALTY;
#endif
/* .. and a slight advantage to the current MM */
if (p->mm == this_mm || !p->mm)
weight += 1;
weight += 20 - p->nice;
goto out;
- 上面的代码片段是针对普通进程的。如果调度策略是SCHED_OTHER,则对应的是普通进程。如果weigt=0代表的是此进程已经没有时间片了,则直接跳出
- 在SMP系统中,如果此进程之前是在当前CPU上运行,因为Cache缓存的特性,会给此类CPU增加对应的时间片,相对应是给惩罚其他进程
- 如果此进程和当前进程共享一个mm_struct结构,或者当前进程是是内核线程,则增加时间片。
- 正常情况下普通进程的动态优先级=剩余的时间片+进程的静态优先级
实时进程则是简单粗暴,直接是在实时进程的静态优先级上加上1000,因为每个实时进程的静态优先级是不一样的。
weight = 1000 + p->rt_priority;
进程时间片的初始化
随着时间的推移,所有的进程的时间片可能都会运行,这时候就需要对所有的进程进行一次时间片的初始化动作
/* Do we need to re-calculate counters? */
if (unlikely(!c))
struct task_struct *p;
spin_unlock_irq(&runqueue_lock);
read_lock(&tasklist_lock);
for_each_task(p)
p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
read_unlock(&tasklist_lock);
spin_lock_irq(&runqueue_lock);
goto repeat_schedule;
也就是当从运行队列中没有找到可以运行的进程时,这时候会对所有的进程重新初始化counter。当然了一直的睡眠的进程可能时间片没有运行完,则需要将睡眠进程剩余的时间片加上。但是为了防止睡眠的IO消耗型进程优先级累计过高,则需要对半分。
时间片更新
系统中的tick中断会来更新当前进程的时间片的。
void update_process_times(int user_tick)
struct task_struct *p = current;
int cpu = smp_processor_id(), system = user_tick ^ 1;
update_one_process(p, user_tick, system, cpu);
if (p->pid)
if (--p->counter <= 0)
p->counter = 0;
p->need_resched = 1;
if (p->nice > 0)
kstat.per_cpu_nice[cpu] += user_tick;
else
kstat.per_cpu_user[cpu] += user_tick;
kstat.per_cpu_system[cpu] += system;
else if (local_bh_count(cpu) || local_irq_count(cpu) > 1)
kstat.per_cpu_system[cpu] += system;
当每次tick中断到来之时,会对counter减1的。如果counter的值为0,则表示时间片已经用光,则需要设置need_resced的标志,在调度点会去判断当前进程是否设置此值,如果设置则进行调度。
O(n)调度器面临的问题
- 时间复杂度问题,时间复杂度是O(n),当系统中的进程很少的时候性能还可以,但是当系统中的进程逐渐增多,选择下一个进程的时间则是逐渐增大。而且当系统中无可运行的进程时,重新初始化进程的时间片也是相当耗时,在系统中进程很多的情况系下。
- SMP扩展问题。当需要picknext下一个进程时,需要对整个runqueue队列进行加锁的操作,spin_lock_irq(&runqueue_lock);当系统中进程数目比较多的时候,则在临界区的时间就比较长,导致其余的CPU自旋比较浪费
- 实时进程的运行效率问题,因为实时进程和普通进程在一个列表中,每次查实时进程时,都需要全部扫描整个列表,导致实时进程不是很“实时”
- CPU资源浪费问题:因为系统中只有一个runqueue,则当运行队列中的进程少于CPU的个数时,其余的CPU则几乎是idle状态,浪费资源
- cache缓存问题:当系统中的进程逐渐减少时,原先在CPU1上运行的进程,不得不在CPU2上运行,导致在CPU2上运行时,cacheline则几乎是空白的,影响效率。
- 总之O(n)调度器有很多问题,不过有问题肯定要解决的。所以在Linux2.6引入了O(1)的调度器。
以上是关于Linux O(n)调度器的主要内容,如果未能解决你的问题,请参考以下文章
Linux(内核剖析):09---进程调度之Linux调度的实现(struct sched_entityschedule())