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 08:32:04 -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

> > 
> > 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.
> 
> Would it not be better for task_numa_compare to skip
> from consideration CPUs that somebody else is already
> trying to migrate a task to, but still search for the
> best location, instead of settling for a worse location
> to migrate to?

Yes its better to skip cpus if they are already in migration.
And we are already doing it with the above patch. However as I said
earlier 

- Task T1 sets Cpu 1 as best_cpu, 
- Task T2 finds cpu1 and skips Cpu1
- Task T1 finds cpu2 slightly better than cpu1.
- Task T1 resets cpu1 as best_cpu, sets best_cpu as cpu2.
- Task T2 finds cpu2 and skips cpu2
- Task T1 finds cpu3 as best_cpu slightly better than cpu2.
- Task T1 resets cpu2 as best_cpu, sets best_cpu as cpu3.
- Task T2 finds cpu3 and skips cpu3

So after this T1 was able to find a cpu but T2 couldn't find a cpu even
though there were 3 cpus that were available for 2 task to swap.

Again, this is too corner case, that I am okay to drop.