Linus Torvalds wrote: > On Tue, 28 Aug 2007, Al Boldi wrote: > > No need for framebuffer. All you need is X using the X.org vesa-driver. > > Then start gears like this: > > > > # gears & gears & gears & > > > > Then lay them out side by side to see the periodic stallings for ~10sec. > > I don't think this is a good test. > > Why? > > If you're not using direct rendering, what you have is the X server doing > all the rendering, which in turn means that what you are testing is quite > possibly not so much about the *kernel* scheduling, but about *X-server* > scheduling! > > I'm sure the kernel scheduler has an impact, but what's more likely to be > going on is that you're seeing effects that are indirect, and not > necessarily at all even "good". > > For example, if the X server is the scheduling point, it's entirely > possible that it ends up showing effects that are more due to the queueing > of the X command stream than due to the scheduler - and that those > stalls are simply due to *that*. > > One thing to try is to run the X connection in synchronous mode, which > minimizes queueing issues. I don't know if gears has a flag to turn on > synchronous X messaging, though. Many X programs take the "[+-]sync" flag > to turn on synchronous mode, iirc.
I like your analysis, but how do you explain that these stalls vanish when __update_curr is disabled? Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
