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

Re: [Xen-devel] Xen default install - no cpufreq on dom0 ?



On Tue, Feb 23, 2016 at 11:55:48PM +0000, Andrew Cooper wrote:
> On 23/02/2016 23:44, Luis R. Rodriguez wrote:
> > On Tue, Feb 23, 2016 at 10:44:56PM +0000, Andrew Cooper wrote:
> >> On 23/02/2016 22:18, Luis R. Rodriguez wrote:
> >>> On Tue, Feb 23, 2016 at 05:00:12PM -0500, Konrad Rzeszutek Wilk wrote:
> >>>> On Tue, Feb 23, 2016 at 12:48:18PM -0800, Luis R. Rodriguez wrote:
> >>>>> For a while now I've been installing Xen from source on my Debian box,
> >>>>> with a default configuration always. This is party why I've run into
> >>>>> compile issues before it seems, but I've also just picked up on
> >>>>> another possible issue. My system on dom0 overheats and shuts itself
> >>>>> off. For a while I didn't think this was Xen related and perhaps
> >>>>> related to the fact that I built this system myself. However, after
> >>>>> running Debian without Xen (rm -rf /boot/xen*; update-grub; reboot;
> >>>>> systemd-detect-virt yield none) it would seem this does not happen.
> >>>>> What's a bit concerning though is even if I run offlineimap in
> >>>>> singlethreaded mode (offlineimap -1) the machine overheats and shuts
> >>>>> itself off, so I don't necessarily need to be doing a lot of work. I
> >>>>> tried compiling the kernel without Xen while running offlineimap as
> >>>>> well with make -j 8 and it doesn't overheat, meanwhile on Xen dom0
> >>>>> just using offlineimap -1 seems to trigger a shutoff rather quickly.
> >>>> What exactly triggers the shutoff.
> >>> Clearly, overheating. I'm not yet sure if its just BIOS/kernel/hypervisor
> >>> induced forced shutdown. Will try again, but this is rather intrusive as
> >>> its on my personal home system.
> >> You have dislodged the heat sync and the processor is shutting down due
> >> to thermal cutout.
> > How do I prevent this ?
> 
> Open up your computer and shuffle things around.  Alternatively unclog
> the fan.  Possibly both.

This wasn't it. It would seem some AMD systems have a boost option
available, disabling that fixes my woes:

echo 0 > /sys/devices/system/cpu/cpufreq/boost

With this my Linux box without Xen survices the most extreme of situations.

On Linux this is implemented as a cpu freq driver callback
cpufreq_driver->set_boost(state), see cpufreq_boost_trigger_state()., on
drivers/cpufreq/cpufreq.c.

I don't find any of this on the Xen hypervisor. How can I address this
on Xen?

> > The difference in operation between dom0 and
> > bare metal is rather extreme. Is this expected ? Is there a clutch
> > I can use ?
> 
> The only thing software can control is now badly things go wrong.  It is
> not the source of the problem.
> 
> Baremetal probably has deep C and P states set up properly, but it will
> still be under clocking as much as it can in an attempt to avoid
> generating as much heat.

Should be under clocking..

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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