From: Julia Lawall <julia.lawall@inria.fr>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Mel Gorman <mgorman@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: EEVDF and NUMA balancing
Date: Sat, 11 Nov 2023 13:56:52 +0100 (CET) [thread overview]
Message-ID: <1757259592.8647357.1699707412428.JavaMail.zimbra@inria.fr> (raw)
In-Reply-To: <20231009102949.GC14330@noisy.programming.kicks-ass.net>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
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
[-- Attachment #2: runtimes.png --]
[-- Type: image/png, Size: 50262 bytes --]
[-- Attachment #3: ua.C.x_yeti-3_6.5.0_performance_2_ev.pdf --]
[-- Type: application/pdf, Size: 466289 bytes --]
[-- Attachment #4: ua.C.x_yeti-3_6.6.0_performance_10_ev.pdf --]
[-- Type: application/pdf, Size: 573472 bytes --]
next prev parent reply other threads:[~2023-11-11 12:57 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 20:25 Julia Lawall
2023-10-03 21:51 ` Peter Zijlstra
2023-10-04 12:01 ` Julia Lawall
2023-10-04 12:05 ` Peter Zijlstra
2023-10-04 16:24 ` Julia Lawall
2023-10-04 17:48 ` Peter Zijlstra
2023-10-04 18:04 ` Julia Lawall
2023-10-09 10:29 ` Peter Zijlstra
2023-10-09 14:07 ` Julia Lawall
2023-11-11 12:56 ` Julia Lawall [this message]
2023-12-18 13:58 ` Julia Lawall
2023-12-18 17:18 ` Vincent Guittot
2023-12-18 22:31 ` Julia Lawall
2023-12-19 17:38 ` Vincent Guittot
2023-12-19 17:51 ` Julia Lawall
2023-12-20 17:09 ` Vincent Guittot
2023-12-21 18:20 ` Julia Lawall
2023-12-22 14:55 ` Vincent Guittot
2023-12-22 15:00 ` Julia Lawall
2023-12-22 15:59 ` Vincent Guittot
2023-12-22 16:18 ` Julia Lawall
2023-12-22 16:29 ` Julia Lawall
2023-12-22 16:42 ` Vincent Guittot
2023-12-28 18:34 ` Julia Lawall
2023-12-29 15:18 ` Julia Lawall
2024-01-04 16:26 ` Vincent Guittot
2024-01-04 16:45 ` Julia Lawall
2024-01-05 14:51 ` Julia Lawall
2024-01-05 16:00 ` Vincent Guittot
2024-01-05 16:39 ` Julia Lawall
2024-01-05 17:27 ` Julia Lawall
2024-01-18 16:35 ` Vincent Guittot
2024-01-18 16:50 ` Julia Lawall
2024-01-18 17:10 ` Vincent Guittot
2024-01-18 17:43 ` Julia Lawall
2024-01-18 22:13 ` Julia Lawall
2024-01-19 11:26 ` Vincent Guittot
2024-01-19 11:33 ` Julia Lawall
2024-01-26 21:20 ` Julia Lawall
2024-03-10 9:39 ` Julia Lawall
2024-01-05 20:45 ` Julia Lawall
2023-12-20 16:39 ` Julia Lawall
2023-12-20 17:11 ` Vincent Guittot
2023-10-04 18:15 ` Ingo Molnar
2023-10-04 18:20 ` Julia Lawall
2023-10-04 19:48 ` Julia Lawall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1757259592.8647357.1699707412428.JavaMail.zimbra@inria.fr \
--to=julia.lawall@inria.fr \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome