[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0000013cba9fa1cf-30aa7f28-2382-492e-bf09-83c8d4cdcba5-000000@email.amazonses.com>
Date: Fri, 8 Feb 2013 16:24:51 +0000
From: Christoph Lameter <cl@...ux.com>
To: Steven Rostedt <rostedt@...dmis.org>
cc: Frederic Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Alessio Igor Bogani <abogani@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Chris Metcalf <cmetcalf@...era.com>,
Geoff Levand <geoff@...radead.org>,
Gilad Ben Yossef <gilad@...yossef.com>,
Hakan Akkan <hakanakkan@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Li Zhong <zhong@...ux.vnet.ibm.com>,
Namhyung Kim <namhyung.kim@....com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [ANNOUNCE] 3.8-rc6-nohz4
On Fri, 8 Feb 2013, Steven Rostedt wrote:
> On Fri, 2013-02-08 at 16:53 +0100, Frederic Weisbecker wrote:
> > 2013/2/7 Christoph Lameter <cl@...ux.com>:
> > > On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
> > >
> > >> Not with hrtick.
> > >
> > > hrtick? Did we not already try that a couple of years back and it turned
> > > out that the overhead of constantly reprogramming a timer via the PCI bus
> > > was causing too much of a performance regression?
> >
> > Yeah Peter said that especially reprogramming the clock everytime we
> > call schedule() was killing the performances. Now may be on some
> > workloads, with the tick stopped, we can find some new results.
>
> I could imagine this being dynamic. If the system isn't very loaded, and
> the scheduler is giving lots of time slices to tasks, then perhaps it
> could switch to a reprogramming the clock based scheduling. Or maybe, we
> could switch to a "skip ticks" method. That is, instead of completely
> disabling the tick, make the tick go off every other time or less, and
> use the NO_HZ code to calculate the missed ticks.
Ok that sounds good. Automatically reducing the HZ as much as possible
would also quiet down the OS and be beneficial for low latency tasks. We
are configuring the kernels here with the lowest HZ that the hardware
allows to reduce the number of events that impact on the app. The main
problem is that the network stack becomes flaky at low HZ.
--
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/
Powered by blists - more mailing lists