On Mon, Oct 28, 2024 at 4:39 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> 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. IIUC, we sent this patch before the 6.12 merge window closed. That's why I was checking if we can get this into 6.12 :) And this is a new driver, so the chances of this breaking anything in 6.12 is close to zero. > Viresh, I think that this falls into your bucket. Anyway, 6.13 is fine, but would appreciate 6.12 (so we get it into LTS). Thanks, Saravana
