Re: [PATCH v2 11/12] MIPS: Report cluster in /proc/cpuinfo

[Marc Zyngier <maz@kernel.org>]

On Tue, 07 Jun 2022 19:27:36 +0100,
Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
> 
> 
> 
> 在 2022/6/6 14:14, Marc Zyngier 写道:
> > On Wed, 25 May 2022 13:10:29 +0100,
> > Dragan Mladjenovic <Dragan.Mladjenovic@syrmia.com> wrote:
> >> From: Paul Burton <paulburton@kernel.org>
> >> 
> >> When >= CM3.5 output cluster number.
> >> 
> >> Signed-off-by: Paul Burton <paulburton@kernel.org>
> >> Signed-off-by: Dragan Mladjenovic <dragan.mladjenovic@syrmia.com>
> >> 
> >> diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
> >> index bb43bf850314..a66e7705315d 100644
> >> --- a/arch/mips/kernel/proc.c
> >> +++ b/arch/mips/kernel/proc.c
> >> @@ -12,6 +12,7 @@
> >>   #include <asm/cpu.h>
> >>   #include <asm/cpu-features.h>
> >>   #include <asm/idle.h>
> >> +#include <asm/mips-cps.h>
> >>   #include <asm/mipsregs.h>
> >>   #include <asm/processor.h>
> >>   #include <asm/prom.h>
> >> @@ -282,6 +283,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> >>   	seq_printf(m, "kscratch registers\t: %d\n",
> >>   		      hweight8(cpu_data[n].kscratch_mask));
> >>   	seq_printf(m, "package\t\t\t: %d\n", cpu_data[n].package);
> >> +	if (mips_cm_revision() >= CM_REV_CM3_5)
> >> +		seq_printf(m, "cluster\t\t\t: %d\n", cpu_cluster(&cpu_data[n]));
> >>   	seq_printf(m, "core\t\t\t: %d\n", cpu_core(&cpu_data[n]));
> >>     #if defined(CONFIG_MIPS_MT_SMP) || defined(CONFIG_CPU_MIPSR6)
> > This will break userspace. Please don't do that.
> Hmm, userspace always parse cpuinfo line by line so I guess it won't be
> a problem if we add a new line here.

Given that you cannot audit all userspace, this is a pretty bold
statement ;-).

> We accumulated some new additions to cpuinfo in past years and there
> was never a single complain for that.

Consider yourself lucky. Other architectures have see tons of
regressions as soon as a /proc file was updated.

> Though I don't like the idea of using CM version to switch on the
> cluster display....

But the other question is *what information* does this bring to a
user? Very little, if at all. And if you want to this to be exhaustive
and usable by SW that runs across architectures, then providing
accurate and parseable topology information is the way to do it, using
a standard interface:

maz@valley-girl:~$ ls -1 /sys/devices/system/cpu/cpu0/topology/
cluster_cpus
cluster_cpus_list
cluster_id
core_cpus
core_cpus_list
core_id
core_siblings
core_siblings_list
package_cpus
package_cpus_list
physical_package_id
thread_siblings
thread_siblings_list

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.