All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: Srikar Dronamraju <srikar@linux.ibm.com>,
	Tim Chen <tim.c.chen@linux.intel.com>
Cc: christophe.leroy@csgroup.eu, linux-kernel@vger.kernel.org,
	ritesh.list@gmail.com, kprateek.nayak@amd.com,
	yu.c.chen@intel.com, vineethr@linux.ibm.com,
	vincent.guittot@linaro.org, npiggin@gmail.com,
	mpe@ellerman.id.au, maddy@linux.ibm.com,
	linuxppc-dev@lists.ozlabs.org, peterz@infradead.org
Subject: Re: [PATCH 0/4] powerpc/topology: Introduce llc_override debugfs
Date: Wed, 14 Oct 2026 09:48:18 +0530	[thread overview]
Message-ID: <baad6173-30e0-45de-ac0a-fd403c869add@linux.ibm.com> (raw)
In-Reply-To: <as79e9ZRXp28QLkG@linux.ibm.com>



On 10/14/26 9:26 AM, Srikar Dronamraju wrote:
> * Shrikanth Hegde <sshegde@linux.ibm.com> [2026-10-14 08:46:11]:
> 
>> On 10/14/26 2:14 AM, Tim Chen wrote:
>>> On Tue, 2026-10-13 at 15:28 +0530, Shrikanth Hegde wrote:
>>>>
>>>
>>> - SMT: patch 3 adds SD_SHARE_LLC only to MC/PKG, so for "smt" the
>>>     flags are as before. I think it is possible for P9 to have
>>>     shared_caches between two cores:
>>>
>>>     /*
>>>      * P9 has a slightly odd architecture where pairs of cores share an L2 cache.
>>>      * This topology makes it *much* cheaper to migrate tasks between adjacent cores
>>>      * since the migrated task remains cache hot. We want to take advantage of this
>>>      * at the scheduler level so an extra topology level is required.
>>>      */
>>>
>>>     the CACHE level also has SD_SHARE_LLC, and highest_flag_domain() picks it, so sd_llc spans
>>>     cpu_l2_cache_map. shared_caches is only set when that map is wider
>>>     than the core's threads, e.g. a P9 core pair sharing an L2:
>>>
>>>       CPU:               0 1 2 3 | 4 5 6 7
>>>       cpu_smt_mask():    core A  | core B
>>>       sd_llc (CACHE):    0-7
>>>
>>>     The ids follow cpu_smt_mask(), so 0-3 and 4-7 get different ids
>>>     while sd_llc and sd_llc_size cover all eight, and
>>>     cpus_share_cache(0, 4) is false, which is incorrect.
>>>
>>
>> Yes. I doubt anyone wants to try this experiment on Power9.
>> But yes, functionally updating the flags is needed.
>>
>> @srikar,
>> That is also the reason for having the disabled. By default on P9,
>> llc will be at CACHE domain. But, one may want to experiment with =smt
>> which i doubt anyone will ever do.
>>
> 
> I think P9 is a very valid point, but I don't think we should look at disable
> as an option just for this.
> 
> I would say, lets keep it simple now, just have an option rather a toggle to
> have LLC as MC/PKG for experimentation purpose. Switch the toggle and it
> does back to regular LLC mode. Also we don't know how the future Power
> Systems LLCs will look like. So keeping it a simple toggle, will reduce pain
> and increase our flexibility for the future.
> 
> Whether the toggle will switch to MC or PKG could be decided based on the
> experiment results.
> 

Ok. So kernel parameter "llc_override=mc/pkg" exclusively for ppc.

llc_override=mc means LLC is at MC.
llc_override=pkg means LLC is at PKG.
No kernel parameter means no change.

Hope that sounds good.

Also this new kernel parameter sounds a distant relative of split_llc.


  reply	other threads:[~2026-10-14  4:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 10:20 [PATCH 0/4] powerpc/topology: Introduce llc_override debugfs Shrikanth Hegde
2026-10-12 10:20 ` [PATCH 1/4] powerpc/topology: Introduce llc_override debug knob Shrikanth Hegde
2026-10-12 12:14   ` Srikar Dronamraju
2026-10-12 14:10     ` Shrikanth Hegde
2026-10-12 10:20 ` [PATCH 2/4] powerpc/topology: Add docs for llc_override Shrikanth Hegde
2026-10-12 10:20 ` [PATCH 3/4] powerpc/topology: Update mc/pkg flags based on llc_override Shrikanth Hegde
2026-10-12 10:20 ` [PATCH 4/4] powerpc/topology: Rebuild sched domains on llc_override change Shrikanth Hegde
2026-10-12 12:19 ` [PATCH 0/4] powerpc/topology: Introduce llc_override debugfs Srikar Dronamraju
2026-10-12 14:14   ` Shrikanth Hegde
2026-10-12 21:15 ` Tim Chen
2026-10-13  9:58   ` Shrikanth Hegde
2026-10-13 20:44     ` Tim Chen
2026-10-14  3:16       ` Shrikanth Hegde
2026-10-14  3:56         ` Srikar Dronamraju
2026-10-14  4:18           ` Shrikanth Hegde [this message]
2026-10-13 10:05   ` Chen, Yu C

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=baad6173-30e0-45de-ac0a-fd403c869add@linux.ibm.com \
    --to=sshegde@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=ritesh.list@gmail.com \
    --cc=srikar@linux.ibm.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vineethr@linux.ibm.com \
    --cc=yu.c.chen@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.