linux-kernel - Re: [RFC PATCH] sched: wakeup buddy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Feb 2013 10:18:32 +0100
From:	Mike Galbraith <efault@....de>
To:	Michael Wang <wangyun@...ux.vnet.ibm.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>, Alex Shi <alex.shi@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ram Pai <linuxram@...ibm.com>,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
	Namhyung Kim <namhyung@...nel.org>
Subject: Re: [RFC PATCH] sched: wakeup buddy

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

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