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 B9D892A8C1; Thu, 31 Jul 2025 20:23:46 +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=1753993429; cv=none; b=jeNsTAE6HDaqbuCn5skvPxnBsUB1TvbKNG2kJ3eXCiq5Vuy2m1JYEDSruz956x1wMtFFMxKuDimKExL7uprwVHpZTJhIKeCKD/AbRutD7+m+sR0qWD+ejlIxoEZdx2URp31L+VgrGmIfL4lzO7TlvGNFZH2D+x7u3ATXnTvPS64= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753993429; c=relaxed/simple; bh=7T5DkLXsWRQRpO8ffb3B/LzNqgFP/7BQVmMO21vl5Zc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u66mMoOB/dPgn4Vy6KuGOCMv98JEVJQWGIJUyMBSZTqWvldJ/i7FnTFnQfmInf1oeLJy8TCCzkgKD2CoSiXBpunebNBJEYv+HbdiGdlMmvcXdptzLFay8c8+wx8btnZ8xkLwqXYFxcRYbCita/ImcKXwYNf4CONzzibIbPjnaJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 A05101A2D; Thu, 31 Jul 2025 13:23:37 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2F9803F5A1; Thu, 31 Jul 2025 13:23:39 -0700 (PDT) Date: Thu, 31 Jul 2025 22:23:24 +0200 From: Beata Michalska To: Viresh Kumar Cc: Prashant Malani , "Rafael J. Wysocki" , Jie Zhan , Ionela Voinescu , Ben Segall , Dietmar Eggemann , Ingo Molnar , Juri Lelli , open list , "open list:CPU FREQUENCY SCALING FRAMEWORK" , Mel Gorman , Peter Zijlstra , Steven Rostedt , Valentin Schneider , Vincent Guittot , z00813676 , sudeep.holla@arm.com Subject: Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs Message-ID: References: <20250722032727.zmdwj6ztitkmr4pf@vireshk-i7> <20250731111324.vv6vsh35enk3gg4h@vireshk-i7> 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=us-ascii Content-Disposition: inline In-Reply-To: <20250731111324.vv6vsh35enk3gg4h@vireshk-i7> On Thu, Jul 31, 2025 at 04:43:24PM +0530, Viresh Kumar wrote: > On 31-07-25, 10:27, Beata Michalska wrote: > > I am still wondering whether cpufreq core is not a better suited place for > > checking whether the CPU is idle. We could potentially try on anther CPU within > > the policy and if there is none, just provide the last known freq ? > > > > @Viresh: What are your thoughts on that ? > > For other platforms (that' don't have counters to read), I think a call to > ->get() to get the currently configured frequency is perfectly fine. Isn't it ? I assume it is. I was just thinking out loud and wasn't suggesting anything otherwise. The reason why I mentioned that is that getting current frequency for an idle CPU seems like smth we could potentially optimise away and save some cycles (fixing other problems on the way, like this one). But if that's undesired for any reason, it's perfectly fine to stay with unconditional calls to `->get()'. --- BR Beata > > -- > viresh