Message-ID: <1460518820.3780.37.camel@suse.de>
Subject: Re: [PATCH RFC] select_idle_sibling experiments
From: Mike Galbraith <mgalbraith@suse.de>
To: Matt Fleming <matt@codeblueprint.co.uk>, Chris Mason <clm@fb.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel@vger.kernel.org
Date: Wed, 13 Apr 2016 05:40:20 +0200
In-Reply-To: <20160412214502.GI2829@codeblueprint.co.uk>
References: <20160405180822.tjtyyc3qh4leflfj@floor.thefacebook.com>
	 <1459927644.5612.41.camel@suse.de>
	 <20160409173034.GA85074@clm-mbp.thefacebook.com>
	 <20160412214502.GI2829@codeblueprint.co.uk>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 917
Lines: 23

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