Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Michael Tokarev <mjt@tls.msk.ru>, kvm <kvm@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: kvm guest: hrtimer: interrupt too slow
Date: Thu, 8 Oct 2009 22:25:21 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0910082217370.9428@localhost.localdomain> (raw)
In-Reply-To: <20091008192223.GA8111@amt.cnet>

On Thu, 8 Oct 2009, Marcelo Tosatti wrote:
> On Thu, Oct 08, 2009 at 10:05:01AM +0200, Thomas Gleixner wrote:
> > On Wed, 7 Oct 2009, Marcelo Tosatti wrote:
> > > On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote:
> > > What about getting rid of the retry loop, instead? So something
> > > like:
> > > 
> > > - run hrtimer callbacks (once)
> > > - while (tick_program_event(expires))
> > > 	expires = ktime_add_ns(expires, dev->min_delta_ns)
> > > 
> > > This way there's no static tuning involved.
> > 
> > And what does that buy us ? We get an timer interrupt right away, so
> > it's not that much different from the retry loop. See below.
> > 
> > > Its not clear to me why the loop is there in the first place.
> > 
> > We get a timer interrupt and handle the expired timers and find out
> > the timer which is going to expire next to reprogram the hardware. Now
> > when we program that expiry time we find out that the timer is already
> > expired. So instead of programming the hardware to fire an interrupt
> > in the very near future which you would do with your loop above we
> > stay in the interrupt handler and expire the timer and any other by
> > now expired timers right away.
> > 
> > The hang check is just there to avoid starving (slow) machines. We do
> > this by spreading the timer interrupts out so that the system can do
> > something else than expiring timers.
> 
> OK, makes sense.
> 
> So why not program only the next tick using the heuristic, without 
> touching min_delta_ns?

That makes a certain amount of sense albeit I really hate that
heuristics crap especially when we know that we run as a guest. 

We better add a function pointer to the clock event device struct
which defaults to "force it to be slow" for real hardware and can be
overridden by paravirt guests.

Also it's not clear to me why the problem does only happen with
kvm_clock and not with acpi_pm timer emulation (according to the
reporter) and is restricted to SMP guests.

>   retry:
>  	/* 5 retries is enough to notice a hang */
> -	if (!(++nr_retries % 5))
> -		hrtimer_interrupt_hanging(dev, ktime_sub(ktime_get(), now));
> +	if (!(++nr_retries % 5)) {
> +		ktime_t try_time = ktime_sub(ktime_get(), now);
> +
> +		do {
> +			for (i = 0; i < 3; i++)
> +				expires_next = ktime_add(expires_next,try_time);
> +		} while (tick_program_event(expires_next, 0));

  This needs at least a WARN_ON_ONCE() or some other way (sysfs, proc,
  ...) where we can find out how often this happens.

Thanks,

	tglx

  reply	other threads:[~2009-10-08 20:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-29 13:12 kvm guest: hrtimer: interrupt too slow Michael Tokarev
2009-09-29 13:47 ` Avi Kivity
2009-09-29 13:58   ` Michael Tokarev
2009-10-05 10:47     ` Avi Kivity
2009-10-03 23:12 ` Marcelo Tosatti
     [not found]   ` <4AC88E7E.8050909@msgid.tls.msk.ru>
2009-10-05  0:50     ` Marcelo Tosatti
2009-10-05  9:31       ` Michael Tokarev
2009-10-06 13:30         ` Michael Tokarev
2009-10-07 23:17   ` Frederic Weisbecker
2009-10-08  0:54     ` Marcelo Tosatti
2009-10-08  7:54       ` Michael Tokarev
2009-10-08  8:06         ` Thomas Gleixner
2009-10-08  8:14           ` Michael Tokarev
2009-10-08  9:29             ` Thomas Gleixner
2009-10-08 14:06               ` Michael Tokarev
2009-10-08 15:06                 ` Thomas Gleixner
2009-10-08 19:52                 ` Marcelo Tosatti
2009-10-09 21:22                   ` Michael Tokarev
2009-10-09 22:27                     ` Frederic Weisbecker
2009-10-09 22:34                       ` Michael Tokarev
2009-10-10  9:18                         ` Michael Tokarev
2009-10-10  9:24                           ` Frederic Weisbecker
2009-10-10 17:37                         ` Marcelo Tosatti
2009-10-08  8:05       ` Thomas Gleixner
2009-10-08 19:22         ` Marcelo Tosatti
2009-10-08 20:25           ` Thomas Gleixner [this message]
2009-10-08 21:02             ` Michael Tokarev
2009-10-10 17:32             ` [PATCH] tune hrtimer_interrupt hang logic Marcelo Tosatti
2009-10-08  8:09     ` kvm guest: hrtimer: interrupt too slow Michael Tokarev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.0910082217370.9428@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=fweisbec@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mjt@tls.msk.ru \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox