[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ze86eH-RDIanc4Ac@arm.com>
Date: Mon, 11 Mar 2024 17:08:08 +0000
From: Catalin Marinas <catalin.marinas@....com>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Mark Rutland <mark.rutland@....com>,
"Christoph Lameter (Ampere)" <cl@...ux.com>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <vireshk@...nel.org>, Will Deacon <will@...nel.org>,
Jonathan.Cameron@...wei.com, Matteo.Carlini@....com,
Valentin.Schneider@....com, akpm@...ux-foundation.org,
anshuman.khandual@....com, Eric Mackay <eric.mackay@...cle.com>,
dave.kleikamp@...cle.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux@...linux.org.uk, robin.murphy@....com,
vanshikonda@...amperecomputing.com, yang@...amperecomputing.com,
Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>
Subject: Re: [PATCH v3] ARM64: Dynamically allocate cpumasks and increase
supported CPUs to 512
On Mon, Mar 11, 2024 at 05:51:04PM +0100, Marek Szyprowski wrote:
> On 11.03.2024 16:22, Catalin Marinas wrote:
> > On Mon, Mar 11, 2024 at 03:56:37PM +0100, Marek Szyprowski wrote:
> >> On 11.03.2024 13:12, Mark Rutland wrote:
> >>> On Fri, Mar 08, 2024 at 09:08:59AM -0800, Christoph Lameter (Ampere) wrote:
> >>>> On Fri, 8 Mar 2024, Marek Szyprowski wrote:
> >>>>>>> It looks that cpufreq-dt and/or opp drivers needs some adjustments
> >>>>>>> related with this change.
> >>>>>> That's strange. Is this with defconfig? I wonder whether NR_CPUS being
> >>>>>> larger caused the issue with this specific code. Otherwise
> >>>>>> CPUMASK_OFFSTACK may not work that well on arm64.
> >>>> cpumask handling must use the accessor functions provided in
> >>>> include/linux/cpumask.h for declaring and accessing cpumasks. It is likely
> >>>> related to the driver opencoding one of the accessors.
> >>> I took a look at both the OPP code and the cpufreq-dt code and it looks like
> >>> those are doign the right thing w.r.t. cpumask manipulation (i.e. they only use
> >>> the cpumask accessors, and use the cpumask_var_*() functions to dynamically
> >>> allocate/free cpumasks). Maybe I've missed something, but superficially those
> >>> look right.
> >>>
> >>> Marek, can you try reverting this commit and trying defconfig + NR_CPUS=512?
> >> Yes, with $subject reverted and CONFIG_NR_CPUS=512 everything works
> >> fine, so it must be something else broken.
> > Thanks for confirming. Would you mind testing the problematic commit
> > with CONFIG_DEBUG_PER_CPU_MAPS enabled? If it doesn't show anything
> > obvious that can be fixed quickly, I'll revert the commit and queue it
> > again after -rc1 for 6.10 (I haven't sent 6.9 the pull request yet).
>
> I've enabled this option, but unfortunately it didn't reveal anything
> more besides the warning and error I've posted in my initial report. I
> will try to analyze this issue further, but I won't manage to do this today.
No worries, thanks for giving this a try.
--
Catalin
Powered by blists - more mailing lists