[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <bc3dd9ed-0fab-4f62-a55b-8ce33fea10f0@app.fastmail.com>
Date: Thu, 22 May 2025 16:10:35 +0100
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Gregory CLEMENT" <gregory.clement@...tlin.com>,
"Thomas Bogendoerfer" <tsbogend@...ha.franken.de>
Cc: "Vladimir Kondratiev" <vladimir.kondratiev@...ileye.com>,
Théo Lebrun <theo.lebrun@...tlin.com>,
"Tawfik Bayouk" <tawfik.bayouk@...ileye.com>,
"Thomas Petazzoni" <thomas.petazzoni@...tlin.com>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: CPS: Optimise delay CPU calibration for SMP
在2025年5月22日周四 下午4:02,Gregory CLEMENT写道:
[...]
>
> I didn't notice this function initially, but upon closer inspection, it
> appears that although the scan process is optimized, it still performs a
> full scan for each CPU during boot. In contrast, with the mask, the
> information is created only once and within an existing loop.
>
> I believe this function would benefit from __cpu_primary_cluster_mask,
> which is why I prefer my current implementation over using
> mips_cps_first_online_in_cluster().
Thanks for clarification!
My concern is __cpu_primary_cluster_mask is pretty limited and the concept
of "primary cpu" is kind of fragile.
To optimize mips_cps_first_online_in_cluster I think the best way forward
would be produce cpumask for each cluster and perform cpumask_or with online
cpu mask at runtime. cluster_cpumask can be reused by other logic later.
Anyway, it's just my two cents.
Thanks
--
- Jiaxun
Powered by blists - more mailing lists