On Mon, Oct 28, 2024 at 01:43:38PM +0100, Rafael J. Wysocki wrote: > On Mon, Oct 28, 2024 at 1:33 PM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > 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 <saravanak@xxxxxxxxxx> wrote: > > > > > > > > On Tue, Oct 1, 2024 at 2:25 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> 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 <viresh.kumar@xxxxxxxxxx> > > > > > > > > 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. > > Well, where would the device ID be defined for this? The spec or > somewhere else? If the latter, then where again? > Yes, we need to figure those details, but I assumed that is the general idea to get it working in ACPI. We can figure out details when we have to add it. > > 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. > > The DT use case is there I think and so I don't want to block it just > because there is no ACPI counterpart. It can be added later if the > use case is relevant enough. Agreed and that was my thoughts as well. -- Regards, Sudeep
