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

["Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>]

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
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users