Re: kvm guest: hrtimer: interrupt too slow

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 8 Oct 2009, Michael Tokarev wrote:

> Thomas Gleixner wrote:
> > On Thu, 8 Oct 2009, Michael Tokarev wrote:
> > > Yesterday I was "lucky" enough to actually watch what's
> > > going on when the delay actually happens.
> > > 
> > > I run desktop environment on a kvm virtual machine here.
> > > The server is on diskless terminal, and the rest, incl.
> > > the window manager etc, is started from a VM.
> > > 
> > > And yesterday, during normal system load (nothing extra,
> > > and not idle either, and all the other guests were running
> > > under normal load too), I had a stall of everyhing on this
> > > X session for about 2..3, maybe 5 secounds.
> > > 
> > > It felt like completely stuck machine. Nothing were moving
> > > on the screen, no reaction to the keyboard etc.
> > > 
> > > And after several seconds it returned to normal.  With
> > > the familiar message in dmesg -- increasing hrtimer etc,
> > > to the next 50%.  (Without a patch from Marcelo at this
> > > time it shuold increase min_delta to a large number).
> > > 
> > > To summarize: there's something, well, more interesting
> > > going on here.  In addition to the scheduling issues that
> > > causes timers to be calculated on the "wrong" CPU etc as
> > 
> > Care to elaborate ?
> 
> Such huge delays (in terms of seconds, not ms or ns) - I don't
> understand how such delays can be explained by sheduling to the
> different cpu etc.  That's what I mean.  I know very little about
> all this low-level stuff so I may be completely out of context,
> but such explanation does not look right to me, simple as that.
> By "scheduling mistakes" we can get mistakes in range of millisecs,
> but not secs.

I'm really missing the big picture here. 

What means "causes timers to be calculated on the "wrong" CPU etc" ?
And what do you consider a "scheduling mistake" ?

Thanks,

	tglx