Re: [Xen-devel] A clocksource question

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

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
>>> /sys/devices/system/clocksource/clocksource0/current_clocksource
>>> xen
>>> kbpc2:~# cat
>>> /sys/devices/system/clocksource/clocksource0/available_clocksource
>>> xen
>>> kbpc2:~# echo "jiffies"
>>>   
>>>> /sys/devices/system/clocksource/clocksource0/current_clocksource
>>>>      
>>> kbpc2:~# dmesg  | tail -1
>>> [ 7898.642404] Override clocksource jiffies is not HRT compatible.
>>> Cannot switch
>>> while in HRT/NOHZ mode
>>> kbpc2:~#
>>>
>>> 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:
> CONFIG_NO_HZ=y
> 
> 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

j.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel