Messages in this thread | | | Date | Mon, 16 Nov 2020 17:41:20 +0000 | From | Will Deacon <> | Subject | Re: Loadavg accounting error on arm64 |
| |
On Mon, Nov 16, 2020 at 05:24:44PM +0000, Mel Gorman wrote: > On Mon, Nov 16, 2020 at 05:49:28PM +0100, Peter Zijlstra wrote: > > > So while we might be able to avoid a smp_rmb() before the read of > > > sched_contributes_to_load and rely on p->on_cpu ordering there, > > > we may still need a smp_wmb() after nr_interruptible() increments > > > instead of waiting until the smp_store_release() is hit while a task > > > is scheduling. That would be a real memory barrier on arm64 and a plain > > > compiler barrier on x86-64. > > > > Wish I read this before sending the changelog > > > I'm mighty confused by your words here; and the patch below. What actual > > scenario are you worried about? > > > > The wrong one apparently. Even if the IRQ is released, the IPI would > deliver to the CPU that should observe the correct value or take the > other path when smp_cond_load_acquire(&p->on_cpu, !VAL) waits for the > schedule to finish so I'm now both confused and wondering why smp_wmb > made a difference at all.
Probably still worth trying Peter's hack to pad the bitfields though, as I think that's still a plausible issue (and one which would appear to be fixed by that smp_wmb() too).
Will
| |