Re: Scheduler fixes

Martin Mares (
Tue, 7 Jul 1998 19:25:26 +0200

> We certainly are aware of what we're doing, and it's not busy waiting.
> Qt uses select() aggressively, but appropriately. Effectively, Qt and
> the application process all of the events from the X server, sending
> new requests as required, and when there are no more outstanding
> events Qt calls select() with a (mostly) non-zero timeout. select()
> forces a reschedule, which often lets the X server process the newly
> generated requests at once instead of waiting for the next tick.
> I run fifteen processes that use Qt at the moment, and my load is
> close to zero. (As measured by the kernel, AND as measured by the
> time to do a large compile.)
> That said, I like your patch. Optimizing Qt further can be a bit of a
> problem on linux, precisely because the kernel often thinks Qt takes
> no time at all to do some work. Your patch would help with that, and
> presumably with other well-optimized select()-based code as well.

Is there any reason for calling select() with a finite timeout in a typical
X application?

Have a nice fortnight

Martin `MJ' Mares   <>
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Beware of programmers who carry screwdrivers..."

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to