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 <a...@linux-foundation.org> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Kevin Hilman <khil...@linaro.org> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> Acked-by: Peter Zijlstra <pet...@infradead.org> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Viresh Kumar <viresh.ku...@linaro.org> > Signed-off-by: Frederic Weisbecker <fweis...@gmail.com>
pgprdI8fxWWd9.pgp
Description: PGP signature
