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 34239C54791 for ; Wed, 13 Mar 2024 17:14:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B74808004F; Wed, 13 Mar 2024 13:14:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD4FD940010; Wed, 13 Mar 2024 13:14:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94F888004F; Wed, 13 Mar 2024 13:14:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7D319940010 for ; Wed, 13 Mar 2024 13:14:06 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 41B4EA0842 for ; Wed, 13 Mar 2024 17:14:06 +0000 (UTC) X-FDA: 81892663692.15.B3CE930 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf30.hostedemail.com (Postfix) with ESMTP id 2CF9280002 for ; Wed, 13 Mar 2024 17:14:03 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=gaE78Dgv; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf30.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710350044; h=from:from:sender: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:dkim-signature; bh=PplELY1KFkbbainlrPdk4FaZv2dPnxhGL2R5dvxZJcc=; b=mEuT65jFMd/JlPFmVCSdP2yVVtuaWkPYzzUURN3YBwfdNtsLw8MHR0d+2QnAbzTuUfFb5C kffOWWHyYdTjcISqR//Aq4vpCzdLDhdPEMioWOt3icbUBoHAAQXlMrvJe/j6In7tbG1lxQ bMBB0YvIz3aeRM/VaInBtHH97TTo8gk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=gaE78Dgv; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf30.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710350044; a=rsa-sha256; cv=none; b=WqkenaCfeiwcTeEnCQK+5EVD+atYdNM26RvXjYCgSlyMyCPru2YoOWZLXnSbJNW78khYv/ gTDW0wGUPuJSrxsP+bZwQQYnW3465zsMLMq4JBAmHh5Vn/8GfFh5cfwCRtYLPAlVVeKdDr 2SqBrf7stvqtH9fuHuH+A3Pw3d3hhHs= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PplELY1KFkbbainlrPdk4FaZv2dPnxhGL2R5dvxZJcc=; b=gaE78DgvKAJxF5LfQGZm9rbZnq Z6g9f1MSGKltQmW+YWLoqsnkeGJUXUGPP1sjsV3PidbKBCS5V9wNQjTXOrlwwmwm5bbV/BxWMAr2x sTjZF0F6PR9AYHWc9+auHzQVw4pZRi7IIZ5xMlKxmn9VcoawshgDsEDKz0zSmdCCE+ZXVUKwRHXLY bdvmNEyOB6vNM01wor0GwCEy0QZ8WoBSHJ97KjFOXz7i368MBndTTPTtjn75tFwxUgqqU3n7bkAHc 6CzEW+lQ1fE9lpgzIG4VkIQ8bJ/vG3Egqoref58CZpLPcRcoFZWM9kQqNYrJ/5MPmamzjixkUvUvW RHj+UJcA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:45220) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rkSAf-0007y7-0R; Wed, 13 Mar 2024 17:13:41 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rkSAX-0004eW-SY; Wed, 13 Mar 2024 17:13:33 +0000 Date: Wed, 13 Mar 2024 17:13:33 +0000 From: "Russell King (Oracle)" To: Marek Szyprowski Cc: Sudeep Holla , Catalin Marinas , "Christoph Lameter (Ampere)" , 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, 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> <432c1980-b00f-4b07-9e24-0bec52ccb5d6@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <432c1980-b00f-4b07-9e24-0bec52ccb5d6@samsung.com> X-Rspamd-Queue-Id: 2CF9280002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: onuyr5fqpd87sf89cu8fkwghitom6zwb X-HE-Tag: 1710350043-522620 X-HE-Meta: U2FsdGVkX1+iUuWLeNNdpXMFdg9LwiwMXBabcKRqpOldLYO4kKpWMMKIBQNqdsbuKjlD3UuTnF5gvuRovfU6kJIQ+f+UGoP8T2C0xqw4ybpkbF83AbD+XxeeZCg8iBAuUTH1YYxMSiz/iXDaqn5lcyeH83jCrp0fx8w+uwhQ+rzHtDRJoBm0tjJ3FhPORa3l8KUjbs+y7QKG2OwL0gIB0LqgfXpmH1ccQduv9hfYwV3KqVsCnRdy4jXgxqLJoq9ngDvS+o8uzMKITrNBQ9rD39rWVhspWuDOpnYNfrnR2rg8ycWOiINCep4djoiJO/IodqVPzsrkJ8knNPAo3k6tep8CeQtJ0tcenFqd9gNIfItG4xykNDehexLNSmf44YgnoSxglxBnvtGAnyuRtDMM+yxjZ07ttG+aLbBAFy/qZUSNi6ca5heIfSMFzPGLgo9HfMdrI0Gqpv+A0+w8XBcaIKviOBMktYEam/lJht+CSfBWir+LFYVXwtSUVe6WZeiFnZwiJTIRCE9tM/c+Oul9peI5qMPPFOZGiALSL+H/0mGRbLyIZHAxzXDc//UFeThQDYDfeFtMCOlfOifHO2ebfDSnoLMj5LheKQ+Yp2Bj5eQoSoRecNoBnnF96jgol+gK47LSyyy66OFR5NLTcaG5LqNdB0p9aXgKg5syHyX3lW5Dv+fMVaJacC14FBPhhrhmBZ2p1re62nA03IjSmJN2tosiK/LAc4swjtDxdIIi4QzD4PB0pLschOfnmSkfQIfmE8qmNwqlo+XdsVAadxY4QpqN1sSY3sILFBcxEjTZYAYjLdMKeJ81mJcm1mj+kE2rg8K2AeyK+dHMo57gK3FReut4qOOEQr3KTIeK3t7kF41ket09h4xOqwoUgH6F5Dw4X1/PKwYA5Su7OvcNuuhrUFT7EBPfKfaS2l9iWx42LlQm8uczT0AD6Dxwc1mDtMTfBI/z6IStgQcE22ePcI3 ESdGLppo VtfkwWA6vy/oDjgqyLQ2+Zf7M+UraKgFqcLpg+3/LI2edkK5kPh9sYncwdPIOV4P563Va4zqVittXwU1W4crEzNaAaqaJB5pD/PUgWnXrnFD1JDs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Wed, Mar 13, 2024 at 05:22:33PM +0100, Marek Szyprowski wrote: > On 13.03.2024 15:35, Sudeep Holla wrote: > > 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. > > I can fully reproduce this issue on Khadas VIM3 and Odroid-N2 boards. > Both Meson A311D SoC based. So, if I'm reading the OPP code and the DTS* files for Khadas VIM3 correctly, these use operating-points-v2, which is parsed by the opp layer. If the opp layer is unable to parse any operating points, it should print "no supported OPPs" and remove the table (thereby preventing the code in question being reached.) So, I wonder whether what you're seeing is a latent bug which is being tickled by the presence of the CPU masks being off-stack changing the kernel timing. I would suggest the printk debug approach may help here to see when the OPPs are begun to be parsed, when they're created etc and their timing relationship to being used. Given the suspicion, it's possible that the mere addition of printk() may "fix" the problem, which again would be another semi-useful data point. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!