Received-SPF: pass (google.com: domain of linux-kernel+bounces-132868-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <3e2558cf-6b25-4e1b-92ab-a248cdf7b271@arm.com>
Date: Fri, 5 Apr 2024 12:59:02 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] sched/fair: allow disabling sched_balance_newidle
 with sched_relax_domain_level
Content-Language: en-US
To: Vitalii Bursov <vitaly@bursov.com>, Ingo Molnar <mingo@redhat.com>,
 Peter Zijlstra <peterz@infradead.org>, Juri Lelli <juri.lelli@redhat.com>,
 Vincent Guittot <vincent.guittot@linaro.org>,
 Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>,
 Mel Gorman <mgorman@suse.de>, Daniel Bristot de Oliveira
 <bristot@redhat.com>, Valentin Schneider <vschneid@redhat.com>,
 linux-kernel@vger.kernel.org, Shrikanth Hegde <sshegde@linux.ibm.com>
References: <cover.1712147341.git.vitaly@bursov.com>
 <3bf726af-e519-4cc2-a692-19a0cf99fca7@arm.com>
 <87543226-1edd-4692-84b5-31bac9cb0c5d@bursov.com>
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
In-Reply-To: <87543226-1edd-4692-84b5-31bac9cb0c5d@bursov.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05/04/2024 12:25, Vitalii Bursov wrote:
> 
> 
> On 05.04.24 12:17, Dietmar Eggemann wrote:
>> On 03/04/2024 15:28, Vitalii Bursov wrote:

[...]

>>>> ====== ===========================================================
>>>>   -1   no request. use system default or follow request of others.
>>>>    0   no search.
>>>>    1   search siblings (hyperthreads in a core).
>>>>    2   search cores in a package.
>>>>    3   search cpus in a node [= system wide on non-NUMA system]
>>>>    4   search nodes in a chunk of node [on NUMA system]
>>>>    5   search system wide [on NUMA system]
>>>> ====== ===========================================================
>>
>> IMHO, this list misses: 
>>
>>       2   search cores in a cluster.
>>
>> Related to CONFIG_SCHED_CLUSTER.
>> Like you mentioned, if CONFIG_SCHED_CLUSTER is not configured MC becomes
>> level=1.
> 
> Previous discussion in v2 on this topic:
> https://lore.kernel.org/linux-kernel/78c60269-5aee-45d7-8014-2c0188f972da@bursov.com/T/#maf4ad0ef3b8c18c8bb3e3524c683b6459c6f7f64

Sorry, I missed this discussion.

I thought that SCHED_CLUSTER is based on shared L3 tags (Arm64
kunpeng920) or L2 cache (X86 Jacobsville) so it's similar to SCHED_MC
just one level down?

> The table certainly depends on the kernel configuraion and describing this
> dependency in detail probably isn't worth it, so how the table should look
> like in the documentation is debatable...

[...]