linux-kernel - Re: [PATCH 16/19] sched/numa: Detect if node actively handling migration

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]

Date:   Wed, 6 Jun 2018 05:55:29 -0700
From:   Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:     Rik van Riel <riel@...riel.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 16/19] sched/numa: Detect if node actively handling
 migration

> > 
> > I thought about this. Lets say we evaluated that destination node can
> > allow movement. While we iterate through the list of cpus trying to
> > find
> > the best cpu node, we find a idle cpu towards the end of the list.
> > However if another task as already raced with us to move a task to
> > this
> > node, then we should bail out. Keeping the check in task_numa_compare
> > will allow us to do this.
> 
> Your check is called once for every invocation
> of task_numa_compare. It does not matter whether
> it is inside or outside, except on the outside
> the variable manipulation will be easier to read.
> 

Okay I mistook your comment; Basically you want the check to be moved
within the for-loop in task_numa_find_cpu.
I will do the needful.

> > 
> > While we can't complete avoid this, the second check will try to make
> > sure we don't hop on/hop off just for small incremental numa
> > improvement.
> 
> However, all those racing tasks start searching
> the CPUs on a node from the same start position.
> 
> That means they may all get stuck on the same
> task/cpu A, and not select the better task/cpu B.

> 
> What am I missing? 

All tasks will not be stuck at task/cpu A.

"[PATCH 10/19] sched/numa: Stop multiple tasks from moving to the
cpu..." the first task to set cpu A as swap target will ensure
subsequent tasks wont be allowed to set cpu A as target for swap till it
finds a better task/cpu. Because of this there a very very small chance
of a second task unable to find a task to swap.