From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
"Christoph Lameter (Ampere)" <cl@linux.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <vireshk@kernel.org>, Will Deacon <will@kernel.org>,
Jonathan.Cameron@huawei.com, Matteo.Carlini@arm.com,
Valentin.Schneider@arm.com, akpm@linux-foundation.org,
anshuman.khandual@arm.com, Eric Mackay <eric.mackay@oracle.com>,
dave.kleikamp@oracle.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux@armlinux.org.uk, robin.murphy@arm.com,
vanshikonda@os.amperecomputing.com, yang@os.amperecomputing.com,
Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v3] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512
Date: Mon, 11 Mar 2024 17:51:04 +0100 [thread overview]
Message-ID: <8c8aea4d-e911-44cd-bbec-ead4e44d338a@samsung.com> (raw)
In-Reply-To: <Ze8hmCbN7_GDRMVS@arm.com>
Hi Catalin,
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.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2024-03-11 16:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 1:45 Christoph Lameter (Ampere)
2024-03-07 17:49 ` Mark Rutland
2024-03-07 19:07 ` Catalin Marinas
2024-03-18 18:17 ` Catalin Marinas
[not found] ` <CGME20240308140130eucas1p1259c805a0b6491ce2f69c6fca0264b1f@eucas1p1.samsung.com>
2024-03-08 14:01 ` Marek Szyprowski
2024-03-08 14:51 ` Catalin Marinas
2024-03-08 16:21 ` Marek Szyprowski
2024-03-08 17:08 ` Christoph Lameter (Ampere)
2024-03-11 12:12 ` Mark Rutland
2024-03-11 14:56 ` Marek Szyprowski
2024-03-11 15:22 ` Catalin Marinas
2024-03-11 16:51 ` Marek Szyprowski [this message]
2024-03-11 17:08 ` Catalin Marinas
2024-03-11 18:55 ` Catalin Marinas
2024-03-11 21:07 ` Christoph Lameter (Ampere)
2024-03-12 17:06 ` Christoph Lameter (Ampere)
2024-03-12 17:55 ` Catalin Marinas
2024-03-13 14:35 ` Sudeep Holla
2024-03-13 16:22 ` Marek Szyprowski
2024-03-13 16:39 ` Christoph Lameter (Ampere)
2024-03-13 20:18 ` Marek Szyprowski
2024-03-13 17:13 ` Russell King (Oracle)
2024-03-14 8:39 ` Catalin Marinas
2024-03-14 12:28 ` Marek Szyprowski
2024-03-14 13:17 ` Russell King (Oracle)
2024-03-14 17:01 ` Christoph Lameter (Ampere)
2024-03-14 13:57 ` Catalin Marinas
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=8c8aea4d-e911-44cd-bbec-ead4e44d338a@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Matteo.Carlini@arm.com \
--cc=Valentin.Schneider@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=dave.kleikamp@oracle.com \
--cc=eric.mackay@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=nm@ti.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sboyd@kernel.org \
--cc=vanshikonda@os.amperecomputing.com \
--cc=vireshk@kernel.org \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.com \
/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