linux-kernel - Re: [PATCH] sched: smart wake-affine

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: <51D27704.20908@linux.vnet.ibm.com>
Date:	Tue, 02 Jul 2013 14:45:24 +0800
From:	Michael Wang <wangyun@...ux.vnet.ibm.com>
To:	Mike Galbraith <efault@....de>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Alex Shi <alex.shi@...el.com>,
	Namhyung Kim <namhyung@...nel.org>,
	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: smart wake-affine

On 07/02/2013 02:29 PM, Mike Galbraith wrote:
> On Tue, 2013-07-02 at 14:17 +0800, Michael Wang wrote:
> 
>> As Peter mentioned before, we currently need some solution like the
>> buddy-idea, and when folks report regression (I suppose they won't...),
>> we will have more data then.
>>
>> So we could firstly try to regain the lost performance of pgbench, if it
>> strip the benefit of other benchmarks, let's fix it, and at last we will
>> have a real smart wake-affine and no one will complain ;-)
> 
> The idea is plenty simple (and the fastpath has a deep and abiding love
> of simple) so the idea itself flies in my book.  It doesn't add as much
> knowledge as may be nice to have, but if it adds enough to help pgbench
> and ilk without harming others, cool.

Nice to know you like it ;-)

There are some thinking behind the idea, since the knob is unacceptable,
I try to make the filter more strict, we actually
could get all the lost 50% performance back, but will run the risk to
strip other's benefit (like hackbench), but if just get 40% performance
back, then we may could reduce the risk nearly to 0.

So the principle of this idea is to filter out the extremely bad cases,
and we make sure under such cases, the chances of mess things up is very
high, thus the wake_affine() will become a little smart and know to stop
in front of the cliff...

Regards,
Michael Wang


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

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