Re: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needsit

[Frederic Weisbecker]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/