Dispatching and scheduling--basic questions
Alan.Coopersmith at Sun.COM
Tue Sep 16 07:42:33 PDT 2008
Adam Jackson wrote:
> That said, we have seen some cases where threading would be a real win.
> Moving input to a thread for latency reasons looks like it's definitely
> worthwhile. Some hardware operations like DDC are slow out of
> proportion to the rest, and might be worth executing asynchronously.
> Fortunately the dispatch code is equipped to handle this; we have the
> ability add things to idle work queues, timers, the ability to put
> clients to sleep for a while and complete their requests once the async
> task finishes, etc.
The old xfs split used those to effectively put some font operations into
a separate thread as well, though one with it's own address space. That
was mainly a win for large Asian-locale fonts with thousands of glyphs
that took a long time to load and process. Most clients today move that
font "thread" into their own process via Xft/render.
The other place Sun found to add threads was in our Xinerama implementation
of OpenGL - it would run a thread per GPU to process GL commands that
crossed multiple screens. Unfortunately, I think that code is locked
away in our licensed-from-a-third-party version of OpenGL. (I guess Xdmx
could be used to essentially simulate thread-per-GPU X, with the penalty
of all that overhead communicating between the master & slave servers.)
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
More information about the xorg