From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E9FBC54791 for ; Wed, 13 Mar 2024 14:35:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 866878002F; Wed, 13 Mar 2024 10:35:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EF46940010; Wed, 13 Mar 2024 10:35:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 669108002F; Wed, 13 Mar 2024 10:35:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 51AAE940010 for ; Wed, 13 Mar 2024 10:35:25 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 26BBD40B4A for ; Wed, 13 Mar 2024 14:35:25 +0000 (UTC) X-FDA: 81892263810.18.D839DDE Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf14.hostedemail.com (Postfix) with ESMTP id DABC5100016 for ; Wed, 13 Mar 2024 14:35:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf14.hostedemail.com: domain of sudeep.holla@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=sudeep.holla@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710340523; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yOQGShewM716dS+uPb9Z8lLXlUwt34drgeAVECPi7Bg=; b=fqCTDawVjexQx8HhNQxGfwD98LzsxD3dd9hGxpJYAjKZvSTBGHqEQV2oWUerhwT0oUYfjm z7Ncnp7CCcyWhpmCbFllF5ezAErfK7b7lzxIKnOYvyGkNUbLumQ8TGHWFw8pzOlEHhgC9C XmRFWBnT5kCTFEXFfQa18o/jRlS5gi8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf14.hostedemail.com: domain of sudeep.holla@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=sudeep.holla@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710340523; a=rsa-sha256; cv=none; b=wXrlmwJXrFmaRg9VY6TGHWRhb5PW/P+Lran7YO4vJg7oCUgEhL6fkSeBDC3VvV5XMiiSCz tJlxqvJKXXdPeVySuBqu6wv6cslNtciEmE8LtEQei33QyoQxnLR2AJziiMBNkICzRTi2Mx uZxp22Cs1Nm1SP9iv3EsBDiyrWaPRe8= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 37BEB1007; Wed, 13 Mar 2024 07:35:58 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D8CDC3F762; Wed, 13 Mar 2024 07:35:17 -0700 (PDT) Date: Wed, 13 Mar 2024 14:35:15 +0000 From: Sudeep Holla To: Catalin Marinas Cc: "Christoph Lameter (Ampere)" , Marek Szyprowski , Mark Rutland , Sudeep Holla , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" , Viresh Kumar , Will Deacon , Jonathan.Cameron@huawei.com, Matteo.Carlini@arm.com, Valentin.Schneider@arm.com, akpm@linux-foundation.org, anshuman.khandual@arm.com, Eric Mackay , 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 , Stephen Boyd Subject: Re: [PATCH v3] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512 Message-ID: References: <37099a57-b655-3b3a-56d0-5f7fbd49d7db@gentwo.org> <9352f410-9dad-ac89-181a-b3cfc86176b8@linux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: DABC5100016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: oh33ud4q5qnutnm59kmngyb3du7xuq1a X-HE-Tag: 1710340522-823578 X-HE-Meta: U2FsdGVkX1+y6LU5GZ5yRIHXhMC3h9fn15tY68G1mejv/kVp/SGYHhzCKRpeUVUmD/LmPEQ7kg1Oo4rLGwrDb9KUm3OEkakP9/d1sdLjbULmdE9Jdma8FkHXnU0GWRJitMycu2vQxsxL6/N5IQIX4OsPSAK04+wcloa2RhwuMT8yGwRST9Rbpl13O20f2PWTMx7zL7B578JXvfCqXMy0cs9J/Sk/0HIc+HepOTQCB6ekMPW407+7ZhD7WOOf2RPB8ocANXJD0nHDSsEVOP3gD4aq28bu1z7DAwhi0pbV6KelDNoddKNF5LrJj1ILEyXupycgDjItsRED/9Pxx8dzhCqmOO1PW8lEVsFzYj8dIbQ9QQdWuVPGgKbQSnmEhbRCRnCElLNMkq23NXA0wfOk7A6NRCuCWzyowsqJj6Q+EbTSqTRqYCIMeo0Zcqfom8eJjEyWOzYyySDyotQsnd3fZPcciuehO6g7opNX/ZsGtzFAoH9olXDSWhV3YwjSSGS4Lz2nDwktXLfe1dmO9wtIlvRp4VijgdSwbF7lpzaL3lZ2ZGzu63kXve0GwThk+UCXMeBQVmFBoJIJACi6K3klxofxfPcfJ3dp87Z6CD1NPovb0/kcylOkLQepd5x0Q7poTXgSkYYN5y/S3cREWv3AbElR2FMOQ1Ep/UBkO4/o1dh1kmQzl0GrmY1szcG3klUrP8xap/fCne3sKjYcoexOLc7rsv20TEuiH7rt0JFovleDvhfE22Lq+esgJN6hEkjIlu8bTFKtSiLKZfBBK6LYjv/KW53NUKPRtxvU5e7+Sr2var6DVQOYhlMfMa2CWGLd3bjpZYt798j5NvsmIw7VykzKLFQdcpC6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 12, 2024 at 05:55:49PM +0000, Catalin Marinas wrote: > On Tue, Mar 12, 2024 at 10:06:06AM -0700, Christoph Lameter (Ampere) wrote: > > On Mon, 11 Mar 2024, Christoph Lameter (Ampere) wrote: > > > > > This could be an issue in the ARM64 arch code itself where there maybe > > > an assumption elsewhere that a cpumask can always store up to NR_CPU > > > cpus and not only nr_cpu_ids as OFFSTACK does. > > > > > > How can I exercise the opp driver in order to recreate the problem? > > > > > > I assume the opp driver is ARM specific? x86 defaults to OFFSTACK so if > > > there is an issue with OFFSTACK in opp then it should fail with kernel > > > default configuration on that platform. > > > > I checked the ARM64 arch sources use of NR_CPUS and its all fine. > > > > Also verified in my testing logs that CONFIG_PM_OPP was set in all tests. > > > > No warnings in the kernel log during those tests. > > > > How to reproduce this? > > I guess you need a platform with a dts that has an "operating-points-v2" > property. I don't have any around. > > Sudeep was trying to trigger this code path earlier, not sure where he > got to. I did try to trigger this on FVP by adding OPPs + some hacks to add dummy clock provider to successfully probe this driver. I couldn't hit the issue reported 🙁. It could be that with the hardware clock/regulator drivers, it take a different path in OPP core. -- Regards, Sudeep