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