linux-kernel - Re: [PATCH v2 00/19] Fixes for sched/numa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180723164735.GI2494@hirez.programming.kicks-ass.net>
Date:   Mon, 23 Jul 2018 18:47:35 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Rik van Riel <riel@...riel.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 00/19]  Fixes for sched/numa_balancing

On Mon, Jul 23, 2018 at 09:29:54AM -0700, Srikar Dronamraju wrote:
> * Peter Zijlstra <peterz@...radead.org> [2018-07-23 17:21:47]:
> 
> > On Mon, Jul 23, 2018 at 08:09:55AM -0700, Srikar Dronamraju wrote:
> > 
> > > > >   sched/numa: Stop multiple tasks from moving to the cpu at the same time
> > > 
> > > This patch has go-ahead from Mel and Rik and no outstanding comments.
> > 
> > I left it out because it's part of the big xchg() mess.
> > 
> > In particular:
> > 
> > +       if (xchg(&rq->numa_migrate_on, 1))
> > +               return;
> > +
> > +       if (env->best_cpu != -1) {
> > +               rq = cpu_rq(env->best_cpu);
> > +               WRITE_ONCE(rq->numa_migrate_on, 0);
> > +       }
> > 
> > I'm again confused by clearing numa_migrate_on at this point..
> 
> First task choose a cpu to swap/migrate, sets the cpu to best_cpu and
> also numa_migrate_on.  Next it finds a better cpu to swap/move. Now if
> the task is able to move to the better cpu, then it should clear
> numa_migrate_on on the previous best_cpu.
> 
> If we dont reset numa_migrate_on on finding a better cpu, the
> numa_migrate_on stays set for the previous cpu, causing previous cpu to
> never be a target of numa balance.

Don't tell me, write better patches.