On 03/12/2010 10:01 PM, Joanna Rutkowska wrote:
> On 03/12/2010 11:02 PM, Jeremy Fitzhardinge wrote:
>> On 03/12/2010 01:56 PM, Tobias Geiger wrote:
>>> kbpc2:~# cat
>>> kbpc2:~# cat
>>> kbpc2:~# echo "jiffies"
>>> kbpc2:~# dmesg | tail -1
>>> [ 7898.642404] Override clocksource jiffies is not HRT compatible.
>>> Cannot switch
>>> while in HRT/NOHZ mode
>>> Seems like it's not possible to switch to jiffies - however:
>>> kbpc2:~# zcat /proc/config.gz | grep NO_HZ
>>> # CONFIG_NO_HZ is not set
>>> but CONFIG_SCHED_HRTICK=y
>> Interesting. BTW, does NO_HZ change the behaviour of this? In
>> principle NO_HZ should be preferable, and particularly in a virtual
>> machine since it should limit the number of timer interrupts.
>> Joanna, are you using NO_HZ?
> Yes, I have:
> BTW, FWIW, I'm attaching my kernel config. It's almost the same as the
> previously mentioned "Young's Dec23" kernel (the only difference being
> some more recent pvops git patches applied and pcifront being enabled as
> a module).
> While trying to switch from xen source to jiffies source, I got the same
> message as Tobias:
> jiffies clocksource is not HRT compatible. Cannot switch while in
> HRT/NOHZ mode
> I can definitely say that this previously mentioned warning from hrtimer
> about interrupt being too slow is the marking of the start of all the
> troubles. E.g. when I run my Dom0 for some time without starting any
> other VMs, the system behaves good, and no warning in dmesg. Only after
> I start a VM, and probably depending on how heavy load it produces, the
> warning appears in Dom0 dmesg and the problem becomes "feelable". And,
> depending on what new "delta" is being chosen, the system is either
> still usable -- e.g. with a delta like in this case:
> hrtimer: interrupt too slow, forcing clock min delta to 82595226 ns
> which is around 80ms (still the very subtle hiccups can be observed when
> you press and hold a key for some time), or totally unusable, if one is
> unlucky, and the "safe" delta got chosen to be something around 0.5s
> (which interestingly happens most often in my case).
> The "clocksource tsc unstable" messages trouble me too BTW. They seem to
> appear before the hrtimer "interrupt too slow" messages.
But this "tsc unstable" message does not seem to be so critical, e.g. I
just started my system (xen clocksource) and started a VM, and got the
usual hrtimer "slow interrupt" warning, and then all the symptoms
started, but there no "tsc unstables" warning in dmesg.
However, I previously missed another message, that seem to occur at the
very beginning of the system life (before I started any other VMs):
Marking TSC unstable due to TSC halts in idle
Description: OpenPGP digital signature
Xen-devel mailing list