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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
