On 03/11/2010 05:55 AM, Jeremy Fitzhardinge wrote:
>> and so, maybe my kbd hiccups are caused by some code executed by
>> the timer interrupt too frequently (maybe too much code executes per
>> each timer interrupt, because of some other bug)? Just a though...
>>
>
> Possibly, but doesn't seem too likely. Can you tell if your hiccups are
> accompanied by bursts of timer interrupts in /proc/interrupts?
>
> There is another possibility, which is that the scheduler is getting
> confused by xen's scheduler clock. Rather than just scheduling based on
> real time, we try to take into account time stolen from a vcpu so that
> it isn't credited against the process (which may have had all its time
> stolen by another domain). But that could just be confusing things.
>
> Does this help?
>
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0d3f07c..9029885 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -161,6 +161,9 @@ static void do_stolen_accounting(void)
> */
> unsigned long long xen_sched_clock(void)
> {
> +#if 1
> + return xen_clocksource_read();
> +#else
> struct vcpu_runstate_info state;
> cycle_t now;
> u64 ret;
> @@ -190,6 +193,7 @@ unsigned long long xen_sched_clock(void)
> preempt_enable();
>
> return ret;
> +#endif
> }
>
Nope, it didn't.
I think that the important clue is this message appearing in my dmesg
(in Dom0 and also in DomUs):
hrtimer: interrupt too slow, forcing clock min delta to 540150561 ns
This is almost 0.5s (!) and I think this might explain my kbd hiccup. I
wrote that I feel it every 10s or so, but when I was playing on my
system without jiffies setting today, I saw this hiccup occurring much
more often; in fact it was more of a "slow keyboard/system" feeling than
a hiccup".
Anyway, this is a comment from the function that displays this warning
(kernel/hrtimer.c):
/*
* After 5 iteration's attempts, we consider that hrtimer_interrupt()
* is hanging, which could happen with something that slows the interrupt
* such as the tracing. Then we force the clock reprogramming for each
future
* hrtimer interrupts to avoid infinite loops and use the min_delta_ns
* threshold that we will overwrite.
* The next tick event will be scheduled to 3 times we currently spend on
* hrtimer_interrupt(). This gives a good compromise, the cpus will spend
* 1/4 of their time to process the hrtimer interrupts. This is enough to
* let it running without serious starvation.
*/
static inline void
hrtimer_interrupt_hanging(struct clock_event_device *dev,
ktime_t try_time)
{
force_clock_reprogram = 1;
dev->min_delta_ns = (unsigned long)try_time.tv64 * 3;
printk(KERN_WARNING "hrtimer: interrupt too slow, "
"forcing clock min delta to %lu ns\n", dev->min_delta_ns);
}
joanna.
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home