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 91A68C54E58 for ; Tue, 12 Mar 2024 17:56:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF9AA6B0189; Tue, 12 Mar 2024 13:56:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BAA3C6B018A; Tue, 12 Mar 2024 13:56:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A72A26B018B; Tue, 12 Mar 2024 13:56:03 -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 980976B0189 for ; Tue, 12 Mar 2024 13:56:03 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 54FCDA0D86 for ; Tue, 12 Mar 2024 17:56:03 +0000 (UTC) X-FDA: 81889140606.08.35229D5 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf17.hostedemail.com (Postfix) with ESMTP id 47F0240006 for ; Tue, 12 Mar 2024 17:56:00 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710266161; a=rsa-sha256; cv=none; b=pZEbbAto5263GpKhGfuZ9rl/y5XyX/efpo7CH2bbsHuxCucgiUs4UeoLNl1Hp0QzUaLPRZ jG7dg7i9o7r3vNa3LqwBizzRGN7tX+NOMwDI20kS3/uLOLgnIjLSapRul1nC3ssuwSxTbE oiTz9ycsvYslcNAtesqg+6jcWhc0snQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710266161; 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: in-reply-to:in-reply-to:references:references; bh=QlXZ7nJyPLWAw42oXnE+0oe8Zgtxgi4zgHVuqk4A5l8=; b=gWrsof17CTSR5fhy3W1mDC7ghs+RGc9fSiQgBuSdaXHLFQvG2NjP14N7E/hTOcq4/gfDlD Hk7RKKuy/50E2O5odHhzavU9pz0yyxbFRQp6m1huxd5sagv7NktoNcl45FMqdCDpUB0BWk +VW9Phu6HYARoHJDxP/E2iN8cFS5dTQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 0D5C9CE18C3; Tue, 12 Mar 2024 17:55:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 132D2C433F1; Tue, 12 Mar 2024 17:55:51 +0000 (UTC) Date: Tue, 12 Mar 2024 17:55:49 +0000 From: Catalin Marinas To: "Christoph Lameter (Ampere)" Cc: Marek Szyprowski , Mark Rutland , "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 , Sudeep Holla 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=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 47F0240006 X-Stat-Signature: r6wtxrqjue3atr38wez3h3zpzzakqarh X-HE-Tag: 1710266160-660867 X-HE-Meta: U2FsdGVkX19sWfOQsEiJS/H6ICo3q5hKs+yPFpfpHkTpJCfNxhLHFkfGybkSuuY0VRrYoCp7ReMP96hYQYOqMa6FTBwNhmzNU17PtfpBFKB6TJmERfeIGaWMjuqeQz+nRIzrMoS8MmEM5zxyfNzsnJ42Tk7Oo0KvEJNFnbZkYKSCNb57kZBZbLn4YmOTcPgArLM1xCyF6w/AV2d2dMJsc3MRxe0JbGZGOFDQ1ObL5iEChGUONGmi002j5E/rV1An2yhzTQ+xzMkZsv8xxQ1JJbR3ANKCNxHfN1EiF6/+561POouUjDn2mM2GQZo5vux3SA+64coP5nees8/zVAoOlQ/F05H01/+9A+mddnW4fpw2YgNPdZJCjFJFov6oylZoaJGuvmYqqAbhPNX0I2y9ZVje6hdigr4ggUnZBBWEUjEqufHX2DAfhAhK1Kajfnic6Mld7FpzHwLhD4qr6fqrGJ9x33o4eHegASMqyIEGsN60LCoIB6nkYY3CJT1xaZ0nT1+GinOcAjJKxqO8Pi9PrYZUrP9uUlTkRS+2l5Q+w8jpa/Yx2/BfxnoEB2AuuxSGKVzZAhf+fMeGrFZseAMBdIu4GdMn9FEwVc9ChFKMre/aHe+ZsYozzgAmBfJATDw8yaccqNXUkt+cftO58OJQCRARPXj4v6D4iumQ7YJR5Y3xoD1suYQdIF7vdONkWriGeELtjHbkKooDla2wvW9D+r0LIQVyp4ARhnr/akcIdx510YFV83elESDNBTfw0kol7baxLDO2qlV40QCvXS1UV09IPSjnpY7pguduBvdrZUEe5HMeu+3SPke8QMi/lmK6x3aADP805/aSbXBOnjmtZvpeV9BFOY2euwFGBh5i+hkiMpnJQJjqo10PBEhXTnl5Fct2OeEiXkRnOC4PRfY3tmYFPOwyKbheb/MSb0sCRbIl9SdREKcPe8nD7iHW5gw3RN3cm0J1TtJZQJsGtnY uSogQzUz AVu6guoyTxs45KqKlojyyM/DLLAgo06LiqONLZBWrWlGOxe0aT92ZFkpYAq7hy9Ztn21l0bbXtr07RSMWXuc02FZ2frGTAy5Q3VfZ8bOwNqamuSMuWfBYLh/PQV32jkkBqtftw8P+XN9BgqwbnvKRBC34kOq5g1XpcBLhiHzpc0Hp9s5uSgpHjnbBnfkwtkLEgw8M19YWqVjGwbQ4KI33U5C2RNrzo4qiudfL1k7dI94BYlGOr9JR4s1pQPMw1YJiG5mEhmSy7f1RtDDXl6Jm7AX6L8fhXwyOf2JHrc2xbKMtLZo3q0O7qVPeiukhNFSiSaQPdXvDAoLcfNzH/v3zm3sKfTbV23JGxIrt 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 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. -- Catalin