Re: A clocksource question

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2918 bytes --]

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.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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