[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110906130323.GC28205@somewhere.redhat.com>
Date: Tue, 6 Sep 2011 15:03:27 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Anton Blanchard <anton@....ibm.com>,
Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
Lai Jiangshan <laijs@...fujitsu.com>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Stephen Hemminger <shemminger@...tta.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tim Pepper <lnxninja@...ux.vnet.ibm.com>,
Paul Menage <paul@...lmenage.org>
Subject: Re: [PATCH 13/32] nohz: Adaptive tick stop and restart on nohz cpuset
On Mon, Aug 29, 2011 at 05:25:36PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-15 at 17:52 +0200, Frederic Weisbecker wrote:
> > When a CPU is included in a nohz cpuset, try to switch
> > it to nohz mode from the timer interrupt if it is the
> > only non-idle task running.
> >
> > Then restart the tick if necessary from the wakeup path
> > if we are enqueuing a second task while the timer is stopped,
> > so that the scheduler tick is rearmed.
>
> Shouldn't you first put the syscall hooks in place before allowing the
> tick to be switched off? It seems this patch is somewhat too early in
> the series.
I don't think it's necessary, that part doesn't depend on userspace hooks.
The whole thing is enabled very late anyway.
> > This assumes we are using TTWU_QUEUE sched feature so I need
> > to handle the off case (or actually not handle it but properly),
> > because we need the adaptive tick restart and what will come
> > along in further patches to be done locally and before the new
> > task ever gets scheduled.
>
> We could certainly remove that feature flag and always use it, it was
> mostly a transition debug switch in case something didn't work or
> performance issues were found due to this.
Ok, good.
> > I also need to look at the ARCH_WANT_INTERRUPTS_ON_CTXW case
> > and the remote wakeups.
>
> Well, ideally we'd simply get rid of that, rmk has some preliminary
> patches in that direction.
Great!
Thanks.
--
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