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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
