Re: [RFC PATCH] sched: wakeup buddy

From: Michael Wang
Date: Thu Feb 28 2013 - 21:18:17 EST


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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

--
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/