Re: [PATCH] sched: wakeup buddy

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Wed, 2013-03-13 at 11:07 +0800, Michael Wang wrote:

> However, we already figure out the logical that wakeup related task
> could benefit from closely running, this could promise us somewhat
> reliable benefit.

I'm not convinced that the 2 task wakeup scenario is the only sane
scenario. Imagine a ring of 3 tasks that wakes each other, if the
machine is loaded enough, those 3 tasks might fit a single cpu just
fine -- esp. if one of those is always idle.

But your strict 1:1 wakeup relation thing will completely fail to
detect this.

> IMHO, that sounds a little easier for users than to make the decision on
> tell me how long to pull tasks together, they may be confused...

Users shouldn't ever need/want/etc.. rely on this. They should just run
their programs and be (reasonably) happy.

> In summary, I think we have two point here need to be considered:
> 
> 1. what about the missed optimize timing, that may benefit
>    some workload (although we haven't found such workload yet).

Missed optimize; as in not calling wake_affine() due to the throttle?
If we're calling it at such a high frequency it is very likely the next
call isn't very far away.

> 2. how many benefit could wake_affine() stuff bring to us,
>    if limit rate benefit us, why don't we remove it?

It could bring the same benefit but at lower overhead, what's the point
of computing the same value over and over again? Also, the rate limit
thing naturally works for the soft/hard-irq case.

Now, there's another detail I thought up, one could only limit the
wake_affine() calls once it starts returning false.