linux-kernel - Re: [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]

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

On Fri, 2013-03-08 at 10:50 +0800, Michael Wang wrote:

> > OK, so there's two issues I have with all this are:
> > 
> >  - it completely wrecks task placement for things like interrupts (sadly I don't
> >      have a good idea about a benchmark where this matters).
> 
> I don't get this point...could you please give more details?

Take for instance a network workload, the hardirq notifies us there's
data buffered, then softirq does a ton of network layer demuxing and
eventually wakes one (or more) tasks to process data. You want these
tasks to move to the waking cpu, it has lots of this data in cache.

Now, neither hard- nor softirq runs in task context (except for -rt) so
it completely fails on what you propose.

We could simply add something like in_softirq() || in_irq() etc.. to
re-enable wake_affine() for those cases unconditionally, but not sure
that's the right thing either.

> >  - yet another random number.. :/
> 
> Correct...well, but that also means flexibility, I suppose different
> system and workload will need some tuning on this knob to gain more
> benefit, by default, they will gain some benefit, small or big.

Nah, it just means another knob nobody knows how to twiddle.

> > Also, I'm starting to dislike the buddy name; its somewhat over-used.
> 
> I have to agree :), any suggestions?

Nah.. I suppose it depends a bit on the shape the final solution takes,
but I'll think about it.

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