[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Does Xen's Dom0 hypervisor based cpufreq support 'schedutil' governor?

  • To: xen-users@xxxxxxxxxxxxx
  • From: "Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>
  • Date: Tue, 23 Aug 2016 15:30:52 -0400
  • Delivery-date: Tue, 23 Aug 2016 19:31:24 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

On 2016-08-23 15:07, lists@xxxxxxxxxxxx wrote:

On Tue, Aug 23, 2016, at 11:55 AM, Austin S. Hemmelgarn wrote:
As far as I understand it, they are independent of the Domain-0 cpufreq
governors (or if they aren't, then Linux and NetBSD have identical
behavior in their CPU frequency governors, which would not surprise me
all that much).

Assuming that's the case, 'ondemand' is the closest to 'schedutil', as
schedutil in Linux is just a smarter version of the ondemand governor.
Ondemand takes only the processor utilization and the current frequency
into account, while schedutil also factors in a bunch of other things.

I'm not a Xen developer myself, but based on my very limited knowledge
of the internals of Xen and my marginally greater knowledge of the
internals of Linux, I'd say it's not likely that a governor equivalent
to schedutil is even possible on Xen without all the domains
co-operating (a lot of the stats that schedutil looks at are derived
from parts of the process state which would translate to guest kernel
internal state in the context of Xen).

In Dom0, with cpufreq=xen set (i.e. hypervisor based cpufreq in use) it looks 
like 'ondemand' is the default
Which is sensible. It provides good power savings when idle (unlike 'performance') and still has minimal impact on performance (unlike 'powersave') and requires no user input to work correctly (unlike 'userspace'). That's also the default in many Linux distributions for the same reason.

        xenpm  get-cpufreq-para all | egrep "scaling_driver|current"
                scaling_driver       : acpi-cpufreq
                current_governor     : ondemand
                scaling_driver       : acpi-cpufreq
                current_governor     : ondemand
                scaling_driver       : acpi-cpufreq
                current_governor     : ondemand
                scaling_driver       : acpi-cpufreq
                current_governor     : ondemand

Notice that the scaling driver is apci-cpufreq -- which is the same as what the 
kernel would use in a non-Xen env.
This is a generic name though. I'm pretty certain that all 4 big BSD derivatives use the same name for their ACPI P-State based cpufreq drivers, and AFAICT, it's the only one in Xen itself.

It'd be nice to find an up to date, authoritative doc on this.  It's pretty 
confusing .
Yeah, sadly it can be hard sometimes to find up-to-date documentation for Xen which doesn't require reading source code.

I don't know why I didn't think of this before, but if you check /sys/devices/system/cpu in Domain-0, you can see if Domain-0 has any cpufreq drivers loaded based on whether or not there's a sub-directory there called cpufreq. Essentially, if you don't see that directory on a Xen system, Xen is handling the CPU frequency scaling. This doesn't of course have anything to do with xenpm (that just talks straight to Xen via /dev (/dev/xen/privcmd IIRC)), but it will tell you whether the Domain-0 kernel is involved or not.

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.