From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1069B263F4A; Mon, 6 Oct 2025 10:54:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759748074; cv=none; b=BgNysi0acQVbGh+n2hrhCEgy84wYa4MiGLFiPe3FLzNuWmbMvpoho95/161dvXRA2S3elzapv71xi2BIJ0y1xn4X+GztE99q4R0j3bojwyFChBm/tikp6Azl6DRKOT8GZic/jxgnCEPO7lqLyPLfRL2txwqotXLXrAaxoji3VCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759748074; c=relaxed/simple; bh=v8nLoXgILBKux4dXsSp4ugfNGb2r1Hlq0mhvGU0+0bc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UBUZ1ziCeptgPI6KakD0Z+0Pe5HlvUljo2Jap7KZ5sdD8unOcOVXN3kuKtN6GHnb2fCXg5OvCasfT3+lXRp/+3JKfGB8+yffUBSKqF0hDSnViy/tksIxzheuxtW+dJcI06xSC/N3gJbmP5k2LRYg+JQowJEiaFBBG/weVtdDu/A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com; spf=none smtp.mailfrom=foss.arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=foss.arm.com 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 4198D1515; Mon, 6 Oct 2025 03:54:23 -0700 (PDT) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 16AF33F66E; Mon, 6 Oct 2025 03:54:28 -0700 (PDT) Date: Mon, 6 Oct 2025 11:54:26 +0100 From: Sudeep Holla To: Ulf Hansson Cc: "Rafael J . Wysocki" , Sudeep Holla , Catalin Marinas , Will Deacon , Mark Rutland , Thomas Gleixner , Maulik Shah , Daniel Lezcano , Vincent Guittot , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] arm64: smp: Implement cpus_has_pending_ipi() Message-ID: <20251006-manipulative-urban-antelope-31101f@sudeepholla> References: <20251003150251.520624-1-ulf.hansson@linaro.org> <20251003150251.520624-3-ulf.hansson@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251003150251.520624-3-ulf.hansson@linaro.org> On Fri, Oct 03, 2025 at 05:02:44PM +0200, Ulf Hansson wrote: > To add support for keeping track of whether there may be a pending IPI > scheduled for a CPU or a group of CPUs, let's implement > cpus_has_pending_ipi() for arm64. > > Note, the implementation is intentionally lightweight and doesn't use any > additional lock. This is good enough for cpuidle based decisions. > I’m not completely against this change, but I’d like to discuss a few points based on my understanding (which might also be incorrect): 1. For systems that don’t use PM domains for idle, wouldn’t this be unnecessary? It might be worth making this conditional if we decide to proceed. 2. I understand this is intended for the DragonBoard 410c, where the firmware can’t be updated. However, ideally, the PSCI firmware should handle checking for pending IPIs if that’s important for the platform. The firmware could perform this check at the CPU PPU/HW level and prevent entering the state if needed. 3. I’m not an expert, but on systems with a large number of CPUs, tracking this for idle (which may or may not be enabled) seems a bit excessive, especially under heavy load when the system isn’t really idling. -- Regards, Sudeep