[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160413155440.xmlzxbrd6flwtli7@floor.thefacebook.com>
Date: Wed, 13 Apr 2016 11:54:40 -0400
From: Chris Mason <clm@...com>
To: Mike Galbraith <mgalbraith@...e.de>
CC: Matt Fleming <matt@...eblueprint.co.uk>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] select_idle_sibling experiments
On Wed, Apr 13, 2016 at 05:40:20AM +0200, Mike Galbraith wrote:
> 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.
Our power sensors show its basically a wash during the production
benchmark runs. Which makes sense because its really only blinking
on/off at very high frequency.
-chris
Powered by blists - more mailing lists