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

Re: cpuidle flag



On Tue, Dec 10, 2024 at 09:42:12PM +0000, Mike wrote:
> Elliott Mitchell wrote:
> > Are you sure?
> 
> > Other trick is "xen_acpi_processor.ko" only enables C-states for which
> > Domain 0 had corresponding vCPUs.
> 
> Without the flag, `xenpm get-cpuidle-states` returns
> 
> ---
> total C-states       : 4
> ---
> 
> for the dom0 CPUs (which are pinned).  But the others only seem to have C0,
> C1.
> 
> `lsmod | grep xen_acpi_processor` returns a line.  Didn't ever enable it, as
> far as I recall.

If you're on Debian, it got added to the scripts due to my bringing it
to the maintainer's attention.

What you've mentioned matches what I've encountered.  I'm fairly sure
this is a bug in xen_acpi_processor.ko.  I've almost got enough
information to point to what is happening.  Just I need to wait for my
next system restart (kernel update) before pointing the finger.

My present workaround is to boot Domain 0 with full processor, but in
/etc/rc.local do `xl vcpu-set 0 ###`.  Linux gracefully handles hot
processor removal, so this is adaquate for the moment.


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





 


Rackspace

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