[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120327121341.GE13196@somewhere>
Date: Tue, 27 Mar 2012 14:13:43 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
linaro-sched-sig@...ts.linaro.org,
Alessio Igor Bogani <abogani@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Avi Kivity <avi@...hat.com>,
Chris Metcalf <cmetcalf@...era.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Geoff Levand <geoff@...radead.org>,
Gilad Ben Yossef <gilad@...yossef.com>,
Ingo Molnar <mingo@...nel.org>,
Max Krasnyansky <maxk@...lcomm.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Stephen Hemminger <shemminger@...tta.com>,
Steven Rostedt <rostedt@...dmis.org>,
Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Zen Lin <zen@...nhuawei.org>
Subject: Re: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needs
it
On Wed, Mar 21, 2012 at 09:54:39AM -0500, Christoph Lameter wrote:
> On Wed, 21 Mar 2012, Frederic Weisbecker wrote:
>
> > If RCU is waiting for the current CPU to complete a grace
> > period, don't turn off the tick. Unlike dynctik-idle, we
> > are not necessarily going to enter into rcu extended quiescent
> > state, so we may need to keep the tick to note current CPU's
> > quiescent states.
>
> Is there any way for userspace to know that the tick is not off yet due to
> this? It would make sense for us to have busy loop in user space that
> waits until the OS has completed all processing if that avoids future
> latencies for the application.
What is the usecase you have in mind? Is it for realtime purpose?
The "tick stopped" is a volatile and relative state.
Relative because if a timer list is enqueued to fire 1 second later,
the tick will be stopped until that happens. How do we consider this (common)
case?
Also as Chris noted it is volatile because the tick can be restarted anytime
for random reasons: the CPU receives an IPI which makes it restart the
periodic tick.
--
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