CFS调度器的原理明白了但是有个地方，搜遍了整个网络也没找到一个合理的解释：
if (delta > ideal_runtime)
resched_task(rq_of(cfs_rq)->curr);
这出代码是在patch：f685ceaca
sched: Strengthen buddies and mitigate buddy induced latencies
ｐａｔｃｈ中描述和是LAST_BUDDY 和 wakeup preemption相关
ｂｕｄｄｙ是什么意思？是调度队列中的而一个缓存，一个缓存LAST_BUDDY，一个是NEXT_BUDDY，其中LAST_BUDDY是上次执行唤醒操作的进程，NEXT_BUDDY是上次被唤醒的进程，这两个操作为什么这么不同？上面的调度还是考虑到普通的大众进程，还是没有考虑到进程冷热性。
为什么这里要单独考虑进程的冷热性？
为什么软件层面要考虑进程的冷热性？
为什么要考虑唤醒的进程和被唤醒的进程，唤醒的进程有什么特征，非唤醒的进程有什么特征？唤醒别人的进程｜被别人唤醒的进程
目前网上没有一个让人信服的回答，还是kernel里的patch comment靠谱些：
ｐａｔｃｈ：4793241be408b3926ee00c704d7da3b3faf3a05f
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Currently we only have a forward looking buddy, that is, we prefer to
schedule to the task we last woke up, under the presumption that its
going to consume the data we just produced, and therefore will have
cache hot benefits.
刚刚被唤醒的进程的进程是有更高的优先级，因为在生产者－消费者模型中，生产者的内容内容很可能是ｈｏｔ的
This allows co-waking producer/consumer task pairs to run ahead of the
pack for a little while, keeping their cache warm. Without this, we
would interleave all pairs, utterly trashing the cache.
否则的话，所有的进程都同等对待，这样对ｃａｃｈｅ的利用不是好事情
This patch introduces a backward looking buddy, that is, suppose that
in the above scenario, the consumer preempts the producer before it
can go to sleep, we will therefore miss the wakeup from consumer to
producer (its already running, after all), breaking the cycle and
reverting to the cache-trashing interleaved schedule pattern.
这个ｐａｔｃｈ中，会反向看看ｂｕｄｄｙ，在上面的生产者消费者模型中，消费者在ｓｌｅｅｐ之前抢占了
The backward buddy will try to schedule back to the task that woke us
up in case the forward buddy is not available, under the assumption
that the last task will be the one with the most cache hot task around
barring current.
除了当前的进程之外，last task是占用ｃａｃｈｅ资源最丰富的ｔａｓｋ
This will basically allow a task to continue after it got preempted.
In order to avoid starvation, we allow either buddy to get wakeup_gran
ahead of the pack.
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝