linux-kernel - Re: [PATCH] riscv: Move call to init_cpu_topology() to later initialization stage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230104104900.aohsn6zemfllub7r@bogus>
Date:   Wed, 4 Jan 2023 10:49:00 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Conor Dooley <conor@...nel.org>
Cc:     Leyfoon Tan <leyfoon.tan@...rfivetech.com>,
        Andrew Jones <ajones@...tanamicro.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ley Foon Tan <lftan.linux@...il.com>
Subject: Re: [PATCH] riscv: Move call to init_cpu_topology() to later
 initialization stage

On Wed, Jan 04, 2023 at 09:49:48AM +0000, Conor Dooley wrote:

[...]

> >> Uhh, so where did this "capacity-dmips-mhz" property actually come from?
> >> I had a quick check of qemu with grep & I don't see anything there that
> >> would add this property.
> >> This property should not be valid on anything other than arm AFAICT.
> >
> >This DT parameter is not in default Qemu. I've added it for testing (see test steps in below). 
> >This is preparation to support asymmetric CPU topology for RISC-V.
> 
> The property is only valid on arm, so how does arm64 deal with such
> asymmetric topologies without it?

I don't think we can deal with asymmetric topologies without this.
Yes we can detect the difference in the CPU types but we can only assume
there are symmetric in terms of performance in absence of this property.

> Why should we "fix" something that may never be a valid dts?
>

I would not say invalid. But surely absence of it must be handled and
we do that for sure. IIRC, here the presence of it is causing the issue.
And if it is present means someone is trying to build it(I do understand
this is Qemu but is quite common these days for power and performance
balance in many SoC)


[...]

> >> 
> >> I know arm64 does this, but there is any real reason for us to do so?
> >> @Sudeep, do you know why arm64 calls that each time?
> 
> I got myself mixed up between places I fiddled with storing the topology, so you can ignore that question Sudeep.
> Clearly it's the one in smp_callin() that gets called for each CPU.
> Woops.
> 

Hmm I should have read all the messages in the thread. Doing by date/time
didn't work well for me 😄.

> >> Or if it is worth "saving" that call on riscv, since arm64 is clearly happily calling
> >> it for many years & calling it later would likely head off a good few allocation
> >> issues (like the one we saw with the topology reworking a few months ago).
> 
> ...but is it still worth moving the function call later to head off any allocation failures if core topology code changes?
>

Agreed, given how we faced similar issues with cacheinfo on few RISC-V
platforms.


-- 
Regards,
Sudeep