mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stian Halseth <stian@itx.no>
To: Jan Engelhardt <jengelh@inai.de>, davem@davemloft.net
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Subject: Re: [PATCH] sparc: populate sysfs cache topology information on sun4v
Date: Mon, 19 Oct 2026 11:49:49 +0200	[thread overview]
Message-ID: <156ed58445e869ffb783bfee0c07bc784f6178ad.camel@itx.no> (raw)
In-Reply-To: <20261018222723.43442-1-jengelh@inai.de>

[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]

Hi Jan, thanks for looking into this!

On Mon, 2026-10-19 at 00:27 +0200, Jan Engelhardt wrote:
> +int init_cache_level(unsigned int cpu)
> +{
> +	struct cpu_cacheinfo *i = get_cpu_cacheinfo(cpu);
> +	i->num_levels = 2;
> +	i->num_leaves = 3;

Using the MD node as the cache id with CACHE_ID set looks to me like
the right way to do it. I tried it on my T4-1 and V240 and have a few
comments.

mdesc.c is also built for sun4u and there the new *_id fields are never
filled in and stay 0, so both CPUs end up sharing every cache. On my
V240 lscpu goes from 128K L1d in 2 instances to 64K in 1, and the same
for L1i and L2. A tlb_type == hypervisor check here, like the one in
setup_per_cpu_areas(), and -ENOENT otherwise puts it back to how it is
today. I tested that too.

The fixed 2 levels / 3 leaves also only fits T1-T3. On the T4-1 L1 and
L2 come out right now (16K and 128K per core, 8 instances), but the
4M L3 shared by all strands is missing. I dumped the cache nodes from
/dev/mdesc on my T4-1 and T7-1:

  T4:  L1i/L1d per core, L2 128K per core, L3 4M shared by all
  M7:  L1i/L1d per core, L2 data per 2 cores + L2 instn per 4 cores
       (both level 2), L3 8M per 4 cores

On M7 the L2 you get is whichever level 2 node fill_in_one_cache()
hits last (data here), labelled Unified. That's what Tony saw on his
S7 too. The missing L3 isn't just cosmetic either. The scheduler,
sched_ext and the page allocator use the last leaf as the LLC, so the
T4 would end up with a per-core 128K L2 as its LLC.

Maybe it's simpler to just walk the MD directly in init_cache_level()
and populate_cache_leaves(), following the same arcs as
fill_in_one_cpu(), and add one leaf per cache node? Then you get the
split L2 and the L3 for free, and cpuinfo_sparc doesn't have to grow.

Tony, about your first list: CACHE_ID is right, it's the flag that
tells the generic code leaf->id is valid. I built the T4 kernel without
it as well, and then nothing shows up at all, cacheinfo just says
"Failed to find cpu0 device node" and gives up. The functions override
the __weak ones in drivers/base/cacheinfo.c, so they have to stay
non-static. The L2 split and the L3 you found on the S7 are real
though.

/Stian



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      parent reply	other threads:[~2026-10-19  9:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-18 22:27 Jan Engelhardt
2026-10-19  0:16 ` Tony Rodriguez
2026-10-19  0:37   ` Tony Rodriguez
2026-10-19  2:32     ` Tony Rodriguez
     [not found]     ` <c7d7a96c-feb9-4676-8cc2-73529e8324ef@gmail.com>
2026-10-19  2:42       ` Tony Rodriguez
2026-10-19  9:49 ` Stian Halseth [this message]

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=156ed58445e869ffb783bfee0c07bc784f6178ad.camel@itx.no \
    --to=stian@itx.no \
    --cc=davem@davemloft.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=jengelh@inai.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@vger.kernel.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

all inboxes | Powered by JetHome®