mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tony Rodriguez <unixpro1970@gmail.com>
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>,
	Stian Halseth <stian@itx.no>
Subject: Re: [PATCH] sparc: populate sysfs cache topology information on sun4v
Date: Sun, 18 Oct 2026 17:16:55 -0700	[thread overview]
Message-ID: <b69a7cd6-7f9d-4c8e-80b9-701a77a6805a@gmail.com> (raw)
In-Reply-To: <20261018222723.43442-1-jengelh@inai.de>

Hi Jan,

On 10/18/26 3:27 PM, Jan Engelhardt wrote:
> The SPARC port does not publish any cache topology information. The
> lscpu utility therefore falls back to assuming the published cache
> sizes are for unshared caches, and as a result, reports way more
> cache than there really is present in the system. On a T5240 machine:
>
> ```
> $ lscpu
> Architecture:          sparc64
>    CPU op-mode(s):      32-bit, 64-bit
>    Byte Order:          Big Endian
> CPU(s):                128
>    On-line CPU(s) list: 0-127
> Model name:            UltraSparc T2 (Niagara2)
>    Thread(s) per core:  4
>    Core(s) per socket:  16
>    Socket(s):           2
>    Flags:               sun4v
> Caches (sum of all):
>    L1d:                 1 MiB (128 instances)
>    L1i:                 2 MiB (128 instances)
>    L2:                  512 MiB (128 instances)
> ```
>
> This patch implements population of the sysfs cacheinfo structures
> for sun4v (systems with mdesc). The proper amount is now reflected in
> lscpu's output:
>
> ```
> Caches (sum of all):
>    L1d:                 128 KiB (16 instances)
>    L1i:                 256 KiB (16 instances)
>    L2:                  8 MiB (2 instances)
> ```
>
> Signed-off-by: Jan Engelhardt <jengelh@inai.de>
> ---
>   arch/sparc/include/asm/cpudata_64.h |  8 +++-
>   arch/sparc/kernel/mdesc.c           | 61 +++++++++++++++++++++++++++++
>   2 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/arch/sparc/include/asm/cpudata_64.h b/arch/sparc/include/asm/cpudata_64.h
> index 056b3c0e7ef9..e28b841ffe23 100644
> --- a/arch/sparc/include/asm/cpudata_64.h
> +++ b/arch/sparc/include/asm/cpudata_64.h
> @@ -18,13 +18,19 @@ typedef struct {
>   	unsigned int	irq0_irqs;
>   	unsigned int	__pad2;
>   
> -	/* Dcache line 2, rarely used */
> +	/* Dcache line 2+3, rarely used */
>   	unsigned int	dcache_size;
>   	unsigned int	dcache_line_size;
> +	unsigned int	dcache_assoc;
> +	unsigned int	dcache_id;
>   	unsigned int	icache_size;
>   	unsigned int	icache_line_size;
> +	unsigned int	icache_assoc;
> +	unsigned int	icache_id;
>   	unsigned int	ecache_size;
>   	unsigned int	ecache_line_size;
> +	unsigned int	ecache_assoc;
> +	unsigned int	ecache_id;
>   	unsigned short	sock_id;	/* physical package */
>   	unsigned short	core_id;
>   	unsigned short  max_cache_id;	/* groupings of highest shared cache */
> diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
> index 23b51a32e96e..029d9d812074 100644
> --- a/arch/sparc/kernel/mdesc.c
> +++ b/arch/sparc/kernel/mdesc.c
> @@ -818,6 +818,7 @@ static void fill_in_one_cache(cpuinfo_sparc *c, struct mdesc_handle *hp, u64 mp)
>   	const u64 *level = mdesc_get_property(hp, mp, "level", NULL);
>   	const u64 *size = mdesc_get_property(hp, mp, "size", NULL);
>   	const u64 *line_size = mdesc_get_property(hp, mp, "line-size", NULL);
> +	const u64 *assoc = mdesc_get_property(hp, mp, "associativity", NULL);
>   	const char *type;
>   	int type_len;
>   
> @@ -828,15 +829,21 @@ static void fill_in_one_cache(cpuinfo_sparc *c, struct mdesc_handle *hp, u64 mp)
>   		if (of_find_in_proplist(type, "instn", type_len)) {
>   			c->icache_size = *size;
>   			c->icache_line_size = *line_size;
> +			c->icache_assoc = assoc ? *assoc : 0;
> +			c->icache_id = mp;
>   		} else if (of_find_in_proplist(type, "data", type_len)) {
>   			c->dcache_size = *size;
>   			c->dcache_line_size = *line_size;
> +			c->dcache_assoc = assoc ? *assoc : 0;
> +			c->dcache_id = mp;
>   		}
>   		break;
>   
>   	case 2:
>   		c->ecache_size = *size;
>   		c->ecache_line_size = *line_size;
> +		c->ecache_assoc = assoc ? *assoc : 0;
> +		c->ecache_id = mp;
>   		break;
>   
>   	default:
> @@ -1251,6 +1258,60 @@ void mdesc_fill_in_cpu_data(cpumask_t *mask)
>   	smp_fill_in_sib_core_maps();
>   }
>   
> +int init_cache_level(unsigned int cpu)
> +{
> +	struct cpu_cacheinfo *i = get_cpu_cacheinfo(cpu);
> +	i->num_levels = 2;
> +	i->num_leaves = 3;
> +	return 0;
> +}
> +
> +int populate_cache_leaves(unsigned int cpu)
> +{
> +	struct cacheinfo *leaf = get_cpu_cacheinfo(cpu)->info_list;
> +	cpuinfo_sparc *cs = &cpu_data(cpu);
> +
> +	leaf->id                    = cs->icache_id;
> +	leaf->attributes            = CACHE_ID;
> +	leaf->level                 = 1;
> +	leaf->type                  = CACHE_TYPE_INST;
> +	leaf->coherency_line_size   = cs->icache_line_size;
> +	leaf->ways_of_associativity = cs->icache_assoc;
> +	leaf->size                  = cs->icache_size;
> +	leaf->priv                  = cs;
> +	if (cs->icache_line_size > 0 && cs->icache_assoc > 0)
> +		leaf->number_of_sets = cs->icache_size / cs->icache_line_size /
> +		                       cs->icache_assoc;
> +	++leaf;
> +
> +	leaf->id                    = cs->dcache_id;
> +	leaf->attributes            = CACHE_ID;
> +	leaf->level                 = 1;
> +	leaf->type                  = CACHE_TYPE_DATA;
> +	leaf->coherency_line_size   = cs->dcache_line_size;
> +	leaf->ways_of_associativity = cs->dcache_assoc;
> +	leaf->size                  = cs->dcache_size;
> +	leaf->priv                  = cs;
> +	if (cs->dcache_line_size > 0 && cs->dcache_assoc > 0)
> +		leaf->number_of_sets = cs->dcache_size / cs->dcache_line_size /
> +		                       cs->dcache_assoc;
> +	++leaf;
> +
> +	leaf->id                    = cs->ecache_id;
> +	leaf->attributes            = CACHE_ID;
> +	leaf->level                 = 2;
> +	leaf->type                  = CACHE_TYPE_UNIFIED;
> +	leaf->coherency_line_size   = cs->ecache_line_size;
> +	leaf->ways_of_associativity = cs->ecache_assoc;
> +	leaf->size                  = cs->ecache_size;
> +	leaf->priv                  = cs;
> +	if (cs->ecache_line_size > 0 && cs->ecache_assoc > 0)
> +		leaf->number_of_sets = cs->ecache_size / cs->ecache_line_size /
> +		                       cs->ecache_assoc;
> +
> +	return 0;
> +}
> +
>   /* mdesc_open() - Grab a reference to mdesc_handle when /dev/mdesc is
>    * opened. Hold this reference until /dev/mdesc is closed to ensure
>    * mdesc data structure is not released underneath us. Store the

Thanks for working on this — publishing proper SPARC cache topology is 
long overdue, and reading associativity from MDESC plus carrying cache 
IDs through cpuinfo_sparc is a sensible direction.


*Full disclosure: I ran this patch through "DeepSeek AI" out of 
curiosity to sanity-check it and I am interested in learning more.  Deep 
Seek AI flagged a few issues that seem worth mentioning:  You may want 
to double check the "Deep Seek AI" review of this patch.

Main blockers

1)    leaf->attributes = CACHE_ID is invalid. attributes is a bitmask of 
CACHE_WRITE_BACK / CACHE_WRITE_THROUGH / etc.; CACHE_ID isn’t a valid 
attribute. It should be 0 or real attribute bits from MDESC.

  2)   Shared-cache reporting is not actually wired up, so T2-class 
machines still show the wrong cache sizes. The patch sets leaf->id = mp 
and leaf->priv = cs, but never fills leaf->shared_cpu_map, and the 
generic detect_cache_attributes() -> cache_shared_cpu_map_setup() path 
doesn’t appear to be invoked on SPARC. As a result, the generic 
cacheinfo code still treats every leaf as private to one CPU, and lscpu 
still multiplies shared cache size by the number of threads — the exact 
bug being reported.

Concretely: with this patch applied, a T5240 would still report L2: 512 
MiB (128 instances) rather than the correct L2: 8 MiB (2 instances) (4 
MB per socket, shared across 64 threads, 2 sockets). A T5120 would still 
report the 4 MB shared L2 as 4 MB × 64 threads = 256 MiB in 64 instances 
, instead of 4 MiB (1 instance). The patch does not change the outcome 
on T2-class hardware because the leaves are still treated as private to 
each CPU.

3)    MDESC level handling is incomplete and mislabels caches on S7/T7. 
fill_in_one_cache() only handles case 1: (L1I/L1D) and case 2: (ecache); 
everything else falls through to default:. On T2/T5240 that happens to 
work because the shared 4 MB is reported at level 2. But on S7-2/T7-1, 
MDESC reports L2 at level 2 and the shared L3 at level 3 — so the L2 
gets stored as ecache_*, and the real L3 is silently ignored. 
cpuinfo_sparc also has no separate l2_* fields, so the data model can’t 
hold both levels.

4) Hardcoded num_levels = 2 / num_leaves = 3 and ecache labeled level 2 
are wrong across the family. T2/T5240: L1I + L1D + shared L2 (no L3). 
S7-2: L1 + shared L2 + shared L3. T7-1: L1 + private L2 + shared L3. The 
leaf count, levels, and types need to be derived from MDESC, not hardcoded.

5)    The new init_cache_level() / populate_cache_leaves() don’t appear 
to be wired into the generic cacheinfo path , so they may never actually 
be called.

Additional issues

6)    leaf->id is int, but the patch stores a truncated u64 MDESC 
handle. ecache_id/ icache_id/ dcache_id are unsigned int, assigned from 
u64 mp. Beyond truncation, assigning u32 → int id can produce negative 
IDs. An index-based or hashed ID would be cleaner.

7)   Growing cpuinfo_sparc needs an asm-offset audit. The struct has a 
“must be 1st” field and SPARC asm accesses cpu_data at fixed offsets in 
places like rtrap_64.S. The patch adds fields after that, so offset 0 is 
preserved, but it should be confirmed that no asm hardcodes offsets into 
the fields that now shift ( sock_id, core_id, max_cache_id, cache 
fields). It also grows the per-CPU area past the “Dcache line 2” region.

8)    The data model has no separate L2 storage for S7/T7. cpuinfo_sparc 
only has ecache_* for the shared cache. To model S7 (shared L2 per 
cluster + shared L3 per socket) and T7 (private L2 per core + shared 
L3), you need distinct l2_* and l3/ ecache_* fields.

9)    The new *_id scheme duplicates existing infrastructure. 
cpuinfo_sparc already has max_cache_id (“groupings of highest shared 
cache”) and smp_fill_in_sib_core_maps(). It’s worth checking whether 
that mechanism should be extended rather than adding six new fields.

10)    num_leaves may not exist in the target kernel. struct 
cpu_cacheinfo gained num_leaves relatively late (~4.16). If the tree is 
older, init_cache_level() won’t compile or won’t allocate the right 
number of leaves.

11)    Missing validation / NULL checks. fill_in_one_cache() 
dereferences *size and *line_size without NULL checks (pre-existing, but 
adjacent to the new code). assoc is checked, which is good, but there’s 
no power-of-two validation, and when assoc == 0 the leaf still publishes 
a size with number_of_sets = 0, which lscpu may render oddly.

12)    “ecache” naming is platform-dependent. Historically “ecache” 
meant L2 on older SPARC; on S7/T7 the external/shared cache is L3. Using 
ecache_* for both with a hardcoded level 2 is semantically confusing; 
the level should come from MDESC.

13)    Style / linkage. The new functions should probably be static; 
there’s mixed indentation versus the file’s tabs; and a checkpatch.pl 
--strict run would be worthwhile.

14)    Error paths always return 0. init_cache_level() and 
populate_cache_leaves() publish leaves even if all MDESC cache data is 
zero/absent, yielding zero-size cache leaves rather than “unknown.”

15)    leaf->priv = cs is probably harmless, but worth confirming 
nothing in the generic path or arch code expects a particular priv type.

A topology-driven fix — dynamic leaves from MDESC, correct levels, 
separate L2/L3 storage, and a shared_cpu_map keyed on sock_id/cluster — 
would make T2/T5240 report 8 MiB L2 in 2 instances and S7-2/T7-1 report 
their shared L3 correctly instead of 64× inflated.

One clarification on the T5240 lscpu output, since it can look partly 
correct: the L1d: 1 MiB (128 instances) and L1i: 2 MiB (128 instances) 
lines are actually right — L1 really is private per core on T2, so 128 
instances is correct. The L2 line is the giveaway: it reports 512 MiB 
(128 instances), i.e. 128 × 4 MB, when a dual-socket T5240 has only 2 
shared 4 MB L2 caches (one per socket), for 8 MiB total in 2 instances . 
The default “every leaf is private” assumption happens to be true for L1 
and false for L2, which is why only the L2 line is inflated. This patch, 
as written, would leave that L2 line unchanged.

In short: on T2-class hardware (T5120/T5240) this patch produces the 
same incorrect lscpu output as unpatched mainline — it does not resolve 
the reported over-reporting there either.

Regards,

Tony


  reply	other threads:[~2026-10-19  0:16 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 [this message]
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

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=b69a7cd6-7f9d-4c8e-80b9-701a77a6805a@gmail.com \
    --to=unixpro1970@gmail.com \
    --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 \
    --cc=stian@itx.no \
    /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®