This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] A clocksource question

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] A clocksource question
From: Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 12 Mar 2010 01:27:28 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Delivery-date: Thu, 11 Mar 2010 16:42:56 -0800
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=P5+jhrlOybeuy+Dz81i56o81z9w=; b=mgk00h9+q7OjdcfuFX9T4WdgicS+Rc4Eq8CerXVMwnATqIPK/9l7sIE3vSzxW48nzS3eXyqIvZeRUrfHFHU7ifCJBT4QuuK6u/rfRECimO4Jw9Zyc6rMztNqp+7AZpy7ZFS2wYkgKVJYKXeN/F+USUIGG+ROjcIH3izrV8MKO/4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B9877CA.4060204@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B962748.90609@xxxxxxxxxxxxxxxxxxxxxx> <4B96DB69.10101@xxxxxxxx 4B981997.4030605@xxxxxxxxxxxxxxxxxxxxxx> <56cc3abf-21f6-4178-b00e-0331538080d9@default> <4FA716B1526C7C4DB0375C6DADBC4EA3554D53F1B0@xxxxxxxxxxxxxxxxxxxxxxxxx> <4B983EC9.2030105@xxxxxxxxxxxxxxxxxxxxxx> <4B98421F.7040102@xxxxxxxx> <4B984533.9030402@xxxxxxxxxxxxxxxxxxxxxx> <4B9877CA.4060204@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3
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

 * 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
 * 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);


Attachment: signature.asc
Description: OpenPGP digital signature

Xen-devel mailing list