[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48cbfb23-aa4d-4e05-9a63-388a6ed6d9df@intel.com>
Date: Thu, 27 Mar 2025 16:10:02 +0800
From: "Chen, Yu C" <yu.c.chen@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: K Prateek Nayak <kprateek.nayak@....com>, <juri.lelli@...hat.com>,
<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
<rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
<vschneid@...hat.com>, <linux-kernel@...r.kernel.org>,
<tim.c.chen@...ux.intel.com>, <tglx@...utronix.de>, <len.brown@...el.com>,
<gautham.shenoy@....com>, <mingo@...nel.org>, <yu.chen.surf@...mail.com>
Subject: Re: [RFC][PATCH] sched: Cache aware load-balancing
On 3/26/2025 5:42 PM, Peter Zijlstra wrote:
> On Wed, Mar 26, 2025 at 05:15:24PM +0800, Chen, Yu C wrote:
>> Thanks for running the test. I think hackbenc/schbench would be the good
>> benchmarks to start with. I remember that you and Gautham mentioned that
>> schbench prefers to be aggregated in a single LLC in LPC2021 or 2022. I ran
>> a schbench test using mmtests on a Xeon server which has 4 NUMA nodes. Each
>> node has 80 cores (with SMT disabled). The numa=off option was appended to
>> the boot commandline, so there are 4 "LLCs" within each node.
>
> We really should look at getting the SnC topology even without SnC being
> in use.
>
I agree, unfortunately it seems that with SNC disabled there is no
information exposed to the OS that can be used to divide the large LLC
into smaller pieces.
thanks,
Chenyu
> The sheer size of these LLCs is untenable.
Powered by blists - more mailing lists