[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110818132531.GA10441@somewhere>
Date: Thu, 18 Aug 2011 15:25:34 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Avi Kivity <avi@...hat.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Anton Blanchard <anton@....ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Lai Jiangshan <laijs@...fujitsu.com>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Paul Menage <menage@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Stephen Hemminger <shemminger@...tta.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tim Pepper <lnxninja@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH 00/32] Nohz cpusets (was: Nohz Tasks)
On Wed, Aug 17, 2011 at 09:36:47AM -0700, Avi Kivity wrote:
> On 08/15/2011 08:51 AM, Frederic Weisbecker wrote:
> >= What's the interface =
> >
> >We use the cpuset interface by adding a nohz flag to it.
> >As long as a CPU is part of a nohz cpuset, then this CPU will
> >try to enter into adaptive nohz mode when it can, even if it is part
> >of another cpuset that is not nohz.
> >
> >
>
> Why not do it unconditionally? That is, if all the conditions are
> fulfilled, disable the tick regardless of any cpuset settings.
Because I'm not sure it's a win on every workload. This involves
some hooks here and there (syscall slow path), IPIs, etc...
But perhaps if one day it is proven to behave better in most cases
then we can make it enabled by default on cpusets?
--
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