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 5D07D1D5CE0; Mon, 28 Oct 2024 12:33:29 +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=1730118811; cv=none; b=ZxKeAUO/vamOtnOCP/9rqEoq5BxBOlprg5+Bn8aJqvjvH59UyG6WIBACWxXy7kFPkVcuk31Aa+kVpbpLDiKhDwVKslphCJYQ/7Nwr/4/1vNr/uVI8xjFvG5GKJrY23g4WL5M29CIPHykybwmqnbz+3mlKgRe7s8gxASJjyDEMd0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730118811; c=relaxed/simple; bh=LUo/4DSAgdM5mhdfwOOB3FQxw3+m/5EaS5mwXq28miw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cn/t2QA62dsNGZJzjT05uGCafhHbstZSoQGBVMz8BKYfdPm5tjuCC69ZVj8scfN/Vom3Svuc5/Mriji1+DyXLhCvZjtoGMtni0XR9HF6zKSc8FeCSy+05dVIbcBSMQIGfZ/lBmPo/ETCePVcTwbyqTqiUGTYcWcqFlezq7rI55U= 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 5F574497; Mon, 28 Oct 2024 05:33:58 -0700 (PDT) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F20B43F73B; Mon, 28 Oct 2024 05:33:25 -0700 (PDT) Date: Mon, 28 Oct 2024 12:33:23 +0000 From: Sudeep Holla To: "Rafael J. Wysocki" Cc: Saravana Kannan , Viresh Kumar , David Dai , Rob Herring , Krzysztof Kozlowski , Sudeep Holla , Conor Dooley , Quentin Perret , Masami Hiramatsu , Will Deacon , Peter Zijlstra , Vincent Guittot , Marc Zyngier , Oliver Upton , Dietmar Eggemann , Pavan Kondeti , Gupta Pankaj , Mel Gorman , kernel-team@android.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 0/2] Improve VM CPUfreq and task placement behavior Message-ID: References: <20240919000837.1004642-1-davidai@google.com> <20241001092544.2tlydouyyc7jwuja@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Oct 28, 2024 at 12:39:31PM +0100, Rafael J. Wysocki wrote: > On Sat, Oct 26, 2024 at 12:26 AM Saravana Kannan wrote: > > > > On Tue, Oct 1, 2024 at 2:25 AM Viresh Kumar wrote: > > > > > > On 18-09-24, 17:08, David Dai wrote: > > > > Hi, > > > > > > > > This patch series is a continuation of the talk Saravana gave at LPC 2022 > > > > titled "CPUfreq/sched and VM guest workload problems" [1][2][3]. The gist > > > > of the talk is that workloads running in a guest VM get terrible task > > > > placement and CPUfreq behavior when compared to running the same workload > > > > in the host. Effectively, no EAS(Energy Aware Scheduling) for threads > > > > inside VMs. This would make power and performance terrible just by running > > > > the workload in a VM even if we assume there is zero virtualization > > > > overhead. > > > > > > > David Dai (2): > > > > dt-bindings: cpufreq: add virtual cpufreq device > > > > cpufreq: add virtual-cpufreq driver > > > > > > > > .../cpufreq/qemu,virtual-cpufreq.yaml | 48 +++ > > > > drivers/cpufreq/Kconfig | 14 + > > > > drivers/cpufreq/Makefile | 1 + > > > > drivers/cpufreq/virtual-cpufreq.c | 333 ++++++++++++++++++ > > > > include/linux/arch_topology.h | 1 + > > > > 5 files changed, 397 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml > > > > create mode 100644 drivers/cpufreq/virtual-cpufreq.c > > > > > > LGTM. > > > > > > Acked-by: Viresh Kumar > > > > Rafael/Viresh, > > > > Nudge... Any chance this will get pulled into 6.12? > > This is not a fix AFAICS, so 6.12 is out of the question. > > As for 6.13, Viresh thinks that this change is a good idea (or he > wouldn't have ACKed it), so it's up to him. I'm still not convinced > that it will work on x86 or anything that doesn't use DT. > +1, I was about to comment on DT bindings patch, but then I assumed it is accepted to have a device object with similar CID and CRS(for register address) in ACPI for example. But yes, the patch itself is not adding support for that yet. If not is not the way, then we need to come up with a way that works for both ACPI and DT. -- Regards, Sudeep