[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<PUZPR04MB4922D5FAC4A8C88023ADB2DBE37DA@PUZPR04MB4922.apcprd04.prod.outlook.com>
Date: Thu, 19 Jun 2025 14:59:45 +0800
From: Jianyong Wu <jianyong.wu@...look.com>
To: K Prateek Nayak <kprateek.nayak@....com>,
Jianyong Wu <wujianyong@...on.cn>, mingo@...hat.com, peterz@...radead.org,
juri.lelli@...hat.com, vincent.guittot@...aro.org
Cc: dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: allow imbalance between LLCs under NUMA
Hi Prateek,
On 6/19/2025 2:30 PM, K Prateek Nayak wrote:
> Hello Jianyong,
>
> On 6/19/2025 11:38 AM, Jianyong Wu wrote:
>> If this change has bad effect for performance, is there any suggestion
>> to mitigate the iperf migration issue?
>
> How big of a performance difference are you seeing? I still don't see
> any numbers from your testing on the thread.
Sorry for that. Here is the data.
On a machine with 8 NUMAs, each with 4 LLCs, totally 128 cores with smt2.
test command:
server: iperf3 -s
client: iperf3 -c 127.0.0.1 -t 100 -i 2
==================================================
default allow imb
25.3 Gbits/sec 26.7 Gbits/sec +5.5%
==================================================
>
>> Or just leave it there?
>
> Ideally, the cache-aware load balancing series [1] should be able to
> address these concerns. I suggest testing iperf with those changes and
> checking if that solves the issues of excessive migration.
>
> [1] https://lore.kernel.org/lkml/
> cover.1750268218.git.tim.c.chen@...ux.intel.com/
>
I know this patch set. Maybe a little heave. I'll check for iperf test.
Thanks
Jianyong
Powered by blists - more mailing lists