Re: [PATCH] sched: wakeup buddy

[Michael Wang]

On 03/08/2013 02:44 PM, Mike Galbraith wrote:
> On Fri, 2013-03-08 at 10:37 +0800, Michael Wang wrote: 
>> On 03/07/2013 05:43 PM, Mike Galbraith wrote:
>>> On Thu, 2013-03-07 at 09:36 +0100, Peter Zijlstra wrote: 
>>>> On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote:
>>>>
>>>>> wake_affine() stuff is trying to bind related tasks closely, but it doesn't
>>>>> work well according to the test on 'perf bench sched pipe' (thanks to Peter).
>>>>
>>>> so sched-pipe is a poor benchmark for this.. 
>>>>
>>>> Ideally we'd write a new benchmark that has some actual data footprint
>>>> and we'd measure the cost of tasks being apart on the various cache
>>>> metrics and see what affine wakeup does for it.
>>>>
>>>> Before doing something like what you're proposing, I'd have a hard look
>>>> at WF_SYNC, it is possible we should disable/fix select_idle_sibling
>>>> for sync wakeups.
>>>
>>> If nobody beats me to it, I'm going to try tracking shortest round trip
>>> to idle, and use a multiple of that to shut select_idle_sibling() down.
>>> If avg_idle approaches round trip time, there's no win to be had, we're
>>> just wasting cycles.
>>
>> That's great if we have it, I'm a little doubt whether it is possible to
>> find a better way to replace the select_idle_sibling() (look at the way
>> it locates idle cpu...) in some cases, but I'm looking forward it ;-)
> 
> I'm not going to replace it, only stop it from wasting cycles when
> there's very likely nothing to gain.  Save task wakeup time, if delta
> rq->clock - p->last_wakeup < N*shortest_idle or some such very cheap
> metric.  Wake ultra switchers L2 affine if allowed, only go hunting for
> an idle L3 if the thing is on another package.  
> 
> In general, I think things would work better if we'd just rate limit how
> frequently we can wakeup migrate each individual task.  

Isn't the wakeup buddy already limit the rate? and by turning the knob,
we could change the rate on our demand.

We want
> jabbering tasks to share L3, but we don't really want to trash L2 at an
> awesome rate.

I don't get it..., it's a task which has 'sleep' for some time, unless
there is no task running on prev_cpu when it's sleeping, otherwise
whatever the new cpu is, we will trash L2, isn't it?

Regards,
Michael Wang

> 
> -Mike
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/