[Pkg-xen-devel] [PATCH 7/9] debian/xen.init: Load xen_acpi_processor on boot

[Elliott Mitchell]

On Tue, Dec 15, 2020 at 09:06:16PM +0100, Hans van Kranenburg wrote:
> On 12/15/20 5:43 PM, Elliott Mitchell wrote:
> > According to appropriate documentation, ENODEV comes from the module
> > itself and not the standard loading process.  In
> > linux-5.9/drivers/xen/xen-acpi-processor.c there are 3 occurrences of
> > ENODEV, so it would be one of those.  One of those has a pr_warn(), so it
> > would directly show up in `dmesg`.  The other two don't look as likely to
> > trigger and I'm unsure what messages they would produce.
> 
> Also looking at the code now.
> 
> There is nothing in dmesg, so it's probably not the first -ENODEV.
> 
> There was a conversation about it on IRC. Others can modprobe it without
> the error. Someone suggested that if you have another thing in place
> that is already involved in power management, it might refuse to load.
> Now, the case here is that the machines I test with are different
> generations of HP Proliant dl360 and we always configure them for
> 'static high power and performance', disabling any form of cpu frequency
> scaling. Maybe that's the reason that something is not available that
> the module would expect to be able to use. Just guessing.

Yeah, that seems a bit of a misfit for xen-acpi-processor.  The first
valuable feature is if you've got a machine which isn't processor
constrained (my case) it will enable Xen putting processors into deeper
power-saving states.  This saves heat and power, which can be quite
valuable if heat is an issue.

The second is you can tell Xen to /not/ use power-saving.  Sounds like
this case is applicable to you.  Instead of turning on power saving, I
think you can turn it off.

Without xen-acpi-processor module loaded, `xenpm` tells you very little
and doesn't do much.  With xen-acpi-processor loaded, `xenpm` can give a
fair amount of information about processor power states.

I believe something akin to your state could be setup with
`xenpm set-max-cstate 0`, followed by
`xenpm set-scaling-minfreq $proc $freq` for every processor $proc and
$freq being the maximum frequency.

My server tends to spend a fair amount of time in lower-power states.
When the fileserver VM is doing data-checks or the build VM is doing
builds, those ask for the higher frequencies and C-state 0 (100% usage).


> > My main Xen machine is presently on Xen 4.11 and kernel 4.19.  
> > 
> > Seems the comment above read_acpi_id() has been broken.  :-(  Right now
> > if Dom0 has fewer vCPUs than the machine has actual processors, the
> > C-states don't get setup for the processors which lack vCPUs.  Workaround
> > I've got right now is hot unplugging some processors after boot.
> 
> Oh, interesting.
> 
> Anyway, since it works for others, it's certainly good that we try to
> load it now. :) Apparently things can be improved even more, but at
> least it's already better than nothing.

Mention `xenpm` since that appears to be the other half of this.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445