This week in the scheduling discussion [LWN.net]

This week in the scheduling discussion

Posted Apr 26, 2007 15:40 UTC (Thu) by pjones (guest, #31722)
Parent article: This week in the scheduling discussion

There's also no way to ensure that X uses the credit for work done on the yielding process's behalf; it could just as easily squander it on wobbly window effects. But it's a step in the right direction.

I'm not so sure that squandry is a reasonable characterization of desktop effects such as "wobbly window[s]", nor that ensuring a strong coupling between credit yielded to X and work it performs is desirable.

If you've got the system configured to draw wobbly windows or other desktop effects, then any failure to draw your application's widgets in reasonable time or to wobble the windows correctly would represent the same failure. In either case, the screen looks bad and usability is degraded; the user suffers. There is no part of the screen that's more important to get right than any other. IT must all look good and perform with sufficient speed and responsiveness for the user to have a favorable experience.

(Log in to post comments)

X scheduling fairness

Posted Apr 27, 2007 15:58 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

There is no part of the screen that's more important to get right than any other.

What if you have a long compile job running in an xterm and are simultaneously browsing the web? Wouldn't you prefer that CPU time go to drawing the browser windows than updating the xterm?

With the proposed approximation to credit transfer, it's possible for the X server to use the browser's credit on behalf of the less urgent compile job.

And even if you're simplistically setting a goal of having each consumer process get the same amount of CPU time, it's possible things would work out so the compile job would get more CPU time than the browser.