linux-kernel - Re: [RFC 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: <51AC384B.8040500@linux.vnet.ibm.com>
Date:	Mon, 03 Jun 2013 14:31:39 +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: [RFC PATCH] sched: smart wake-affine

On 06/03/2013 02:05 PM, Mike Galbraith wrote:
> On Mon, 2013-06-03 at 13:50 +0800, Michael Wang wrote: 
>> On 06/03/2013 01:22 PM, Mike Galbraith wrote:
>> [snip]
>>>>
>>>> I agree that this idea, in other work, 'stop wake-affine when current is
>>>> busy with wakeup' may miss the chance to bring benefit, although I could
>>>> not find such workload, but I can't do promise...
>>>
>>> Someday we'll find the perfect balance... likely the day before the sun
>>> turns into a red giant and melts the earth.
>>
>> Won't take so long ;-)
>>
>> I would like to stop the regression on pgbench firstly, as PeterZ
>> mentioned, if someone reported other regressions, we will know what is
>> missing, if fix is possible, we fix it, if cost is too high, then I say
>> we ignore the illegal income, after all, we could not benefit one in the
>> cost of sacrifice others...
>>
>> I'd like to fix the problem ASAP, it's really a big, urgent problem on
>> my point of view, but doesn't win enough attentions as I thought it will...
> 
> I fully agree that it's a problem, but not that it's a regression.  

I won't disagree, it's just the view point, I used to compare the whole
thing with/without wake-affine stuff, and I found it damage pgbench to
benefit hackbench, furthermore, that was in mainline by default...

The
> "we became too buddy-centric" problem has existed for a long time, it's
> just that pgbench in 1:N mode shows us how much that pull pull pull can
> cost us in scalability.

Agree, that was something we missed when we are so happily figure out
the good-side of pull...

> 
> A much more interesting pgbench test (imho) would be with one server per
> socket. 

May be configure the database could achieve that, sounds like a better
deployment to me ;-)

1 server (mother of all work) driving a multi-socket sized load
> is just silly, can't possibly scale, so it's important that improving
> 1:N pgbench (we can, and need to) doesn't harm sane loads.

I guess the pgbench behaviour is badly depends on the database
configuration on box, I think there are still many interesting points we
could dig :)

Anyway, I still prefer to do it step by step, if we do not fix the issue
we already found, then the deeper research will based on an forked
unreal world...

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/