Messages in this thread | | | Subject | Re: [PATCH] sched: wakeup buddy | From | Peter Zijlstra <> | Date | Thu, 14 Mar 2013 11:58:31 +0100 |
| |
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.
| |