linux-kernel - Re: EEVDF and NUMA balancing

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:   Sat, 11 Nov 2023 13:56:52 +0100 (CET)
From:   Julia Lawall <julia.lawall@...ia.fr>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Mel Gorman <mgorman@...e.de>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: EEVDF and NUMA balancing

A small update.

Attached are graphs of the running times of 50 runs, including 6.5 and 6.6, and graphs showing the events in slow runs with 6.5 and 6.5.

NUMA balancing is shown in dark green lines connecting the source and the destination.  Yellow lines indicate load balancing within a socket.  The cores are renumbered so that adjacent ones are on the same socket.

There is actually more NUMA balancing in these runs in 6.5 than in 6.6.  In general, I don't see a correlation between the amount of NUMA balancing and the running time.  I have the impression that rather the NUMA balancing leads to some socket being overloaded, and then attempts to resolve that continually fail.

The only hint of a solution that I have so far is that the timeslice length may be related.  Or rather the fact that all of the timeslices have length 1 tick.  In runtimes.png I also show what happens if I take 6.5 and replace the return value of sched_slice by 1.  The results are not exactly the same as 6.6 (green vs pink), but they do end up in the same place.  And it may be related to the fact that the time slices are all the same, but to the fact that they are all short, because making sched_slice return 8 gives the same trend, but even worse.

julia
Download attachment "runtimes.png" of type "image/png" (50262 bytes)

Download attachment "ua.C.x_yeti-3_6.5.0_performance_2_ev.pdf" of type "application/pdf" (466289 bytes)

Download attachment "ua.C.x_yeti-3_6.6.0_performance_10_ev.pdf" of type "application/pdf" (573472 bytes)