lkml.org 
[lkml]   [2020]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2020-11-16 18:48    [W:3.593 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site