linux-kernel - Re: [PATCH RFC] select_idle

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: <1460518820.3780.37.camel@suse.de>
Date:	Wed, 13 Apr 2016 05:40:20 +0200
From:	Mike Galbraith <mgalbraith@...e.de>
To:	Matt Fleming <matt@...eblueprint.co.uk>, Chris Mason <clm@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] select_idle_sibling experiments

On Tue, 2016-04-12 at 22:45 +0100, Matt Fleming wrote:
> On Sat, 09 Apr, at 01:30:34PM, Chris Mason wrote:
> > 
> > [ nohz throttling patch ]
> > 
> > I tested the nohz throttle two different ways, first with schbench's
> > pipe simulation, it's easily 8% faster with messages bouncing between
> > cpus.
> > 
> > In production it's hard to pick a single number because the benchmarks
> > produce latency curves as the workload scales up in RPS.  The benefits
> > range from 2-9% depending on the metric.  It's a nice win, and I'd love to
> > see it go in.
> 
> Do we have any idea what the tradeoff is against power consumption for
> throttling nohz?

That's measurable with the built in super duper watt meter gizmo
(turbostat).  It should be dinky but existent, could be given an off
button for particularly attentive laptop drivers to poke.  Servers
drivers are unlikely to care given the performance win.

	-Mike