Re: [PATCH 3/3] nohz: Use IPI implicit full barrier against rq->nr_running r/w

2014-05-14 Thread Frederic Weisbecker
On Wed, May 14, 2014 at 11:09:03AM +0200, Peter Zijlstra wrote: > On Wed, May 14, 2014 at 12:25:56AM +0200, Frederic Weisbecker wrote: > > @@ -670,10 +670,11 @@ bool sched_can_stop_tick(void) > > > > rq = this_rq(); > > > > - /* Make sure rq->nr_running update is visible after the

Re: [PATCH 3/3] nohz: Use IPI implicit full barrier against rq->nr_running r/w

2014-05-14 Thread Peter Zijlstra
On Wed, May 14, 2014 at 12:25:56AM +0200, Frederic Weisbecker wrote: > @@ -670,10 +670,11 @@ bool sched_can_stop_tick(void) > > rq = this_rq(); > > - /* Make sure rq->nr_running update is visible after the IPI */ > - smp_rmb(); > - > - /* More than one running task nee

[PATCH 3/3] nohz: Use IPI implicit full barrier against rq->nr_running r/w

2014-05-13 Thread Frederic Weisbecker
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

[PATCH 3/3] nohz: Use IPI implicit full barrier against rq->nr_running r/w

2014-03-19 Thread Frederic Weisbecker
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 restart its tick to maintain local fairness and other accounting details. This notification is performed by way of an IPI. Then when the target rece