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

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: <51847077.6050609@linux.vnet.ibm.com>
Date:	Sat, 04 May 2013 10:20: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 <a.p.zijlstra@...llo.nl>,
	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: wake-affine throttle

On 05/03/2013 02:14 PM, Mike Galbraith wrote:
> On Fri, 2013-05-03 at 13:57 +0800, Michael Wang wrote: 
>> Hi, Mike
>>
>> Thanks for your reply.
>>
>> On 05/03/2013 01:01 PM, Mike Galbraith wrote:
>> [snip]
>>>>
>>>> If this approach caused any concerns, please let me know ;-)
>>>
>>> I wonder if throttling on failure is the way to go.  Note the minimal
>>> gain for pgbench with the default 1ms throttle interval.  It's not very
>>> effective out of the box for the load type it's targeted to help, and
>>> people generally don't twiddle scheduler knobs.  If you throttle on
>>> success, you directly restrict migration frequency without that being
>>> affected by what other tasks are doing.  Seems that would be a bit more
>>> effective.
>>
>> This is a good timing to make some conclusion for this problem ;-)
>>
>> Let's suppose when wake-affine failed, next time slice got a higher
>> failure chance, then whether throttle on failure could be the question like:
>>
>> 	throttle interval should cover more failure timing
>> 	or more success timing?
>>
>> Obviously we should cover more failure timing, since it's just wasting
>> cycle and change nothing.
>>
>> However, I used to concern about the damage of succeed wake-affine at
>> that rapid, sure it also contain the benefit, but which one is bigger?
>>
>> Now if we look at the RFC version which throttle on succeed, for
>> pgbench, we could find that the default 1ms benefit is < 5%, while the
>> current version which throttle on failure bring 7% at most.
> 
> OK, so scratch that thought.  Would still be good to find a dirt simple
> dirt cheap way to increase effectiveness a bit, and eliminate the knob.
> Until a better idea comes along, this helps pgbench some, and will also
> help fast movers ala tbench on AMD, where select_idle_sibling() wasn't
> particularly wonderful per my measurements.

Yep, another advantage of this approach is simple, when later we figure
out the better idea, it could be easily replaced, for now, I would
prefer to use it as an urgent rescue for the 'suffered workload' ;-)

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/