Re: [RFC PATCH] sched: wakeup buddy

[Michael Wang <wangyun@linux.vnet.ibm.com>]

On 02/28/2013 05:18 PM, Mike Galbraith wrote:
> On Thu, 2013-02-28 at 16:49 +0800, Michael Wang wrote: 
>> On 02/28/2013 04:24 PM, Mike Galbraith wrote:
>>> On Thu, 2013-02-28 at 16:14 +0800, Michael Wang wrote: 
>>>> On 02/28/2013 04:04 PM, Mike Galbraith wrote:
>>>
>>>>> It would be nice if it _were_ a promise, but it is not, it's a hint.
>>>>
>>>> Bad to know :(
>>>>
>>>> Should we fix it or this is by designed? The comments after WF_SYNC
>>>> cheated me...
>>>
>>> You can't fix it, because it's not busted.  You can say "Ok guys, I'm
>>> off for a nap RSN" all you want, but that won't guarantee that nobody
>>> pokes you, and hands you something more useful to do than snoozing.
>>
>> So sync still means current is going to sleep, what you concerned is
>> this promise will be easily broken by other waker, correct?
> 
> That makes it a lie, and it can already have been one with no help.
> Just because you wake one sync does not mean you're not going to find
> another to wake.  Smart tasks are taught to look before they leap.
> 
>> Hmm.. may be you are right, if 'perf bench sched pipe' is not the one we
>> should care, I have no reason to add this logical currently.
> 
> Well, there is reason to identify task relationships methinks, you just
> can't rely on the fact that you're alone on the rq at the moment, and
> doing a sync wakeup to bind tasks.  They _will_ lie to you :)

I see.

> 
>> I will remove this plus branch, unless I found other benchmark could
>> benefit a lot from it.
>>
>> Besides this, how do you think about this idea?
> 
> I like the idea of filtering true buddy pairs, and automagically
> detecting the point when 1:N wants spreading rather a lot (fwtw).  I'll
> look closer at your method, but when it comes to implementation
> opinions, the only one I trust comes out of a box in front of me.

And please let me know how it works on your box ;-)

Regards,
Michael Wang

> 
> I'm somewhat.. "taste challenged", Peter and Ingo have some though :)
> 
> -Mike
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>