On Tue, Jun 03, 2014 at 04:40:20PM +0200, Frederic Weisbecker wrote: > A full dynticks CPU is allowed to stop its tick when a single task runs. > Meanwhile when a new task gets enqueued, the CPU must be notified so that > it can restart its tick to maintain local fairness and other accounting > details. > > This notification is performed by way of an IPI. Then when the target > receives the IPI, we expect it to see the new value of rq->nr_running. > > Hence the following ordering scenario: > > CPU 0 CPU 1 > > write rq->running get IPI > smp_wmb() smp_rmb() > send IPI read rq->nr_running > > But Paul Mckenney says that nowadays IPIs imply a full barrier on > all architectures. So we can safely remove this pair and rely on the > implicit barriers that come along IPI send/receive. Lets > just comment on this new assumption. > > Cc: Andrew Morton <[email protected]> > Cc: Ingo Molnar <[email protected]> > Cc: Kevin Hilman <[email protected]> > Cc: Paul E. McKenney <[email protected]> Acked-by: Peter Zijlstra <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: Viresh Kumar <[email protected]> > Signed-off-by: Frederic Weisbecker <[email protected]>
pgprdI8fxWWd9.pgp
Description: PGP signature
