Not to thread the X server [was: to thread the X server]
vignatti at c3sl.ufpr.br
Wed Jun 18 15:39:23 PDT 2008
Juliusz Chroboczek escreveu:
> The fundamental goal of this work is to avoid the mouse pointer
> lagging behind the mouse. In the traditional X11R5 implementation,
My first intention one year ago was to avoid the cursor lag, but now I
can go further exploring other aspects such as the overall performance
of the server.
> the mouse cursor will lag if WaitForSomething is not called often
> enough. This can happen for two reasons:
> 1. the server is stuck executing some long-lived request, such as
> a large PolyLine, font rasterisation, or a GLX request; or
> 2. the server code is not executing at all because it is swapped out.
> (Something that you do not mention is that the issue of long-lived
> requests is mostly a thing of the past. PolyLines are not that
> common, fonts are mostly client side, and OpenGL is usually client-side
> due to DRI.)
good point. In fact, we would have to characterize the workload of a
common usage and see if the currently scheduler is fair enough. A new
dynamic/adaptive scheduler would be also cool.
> So what remains is case (2), the X server getting swapped out. You
> have found out that putting the mouse code in a separate thread does
> not help much, since the thread's code is being swapped out together
> with the rest of the server. Your solution is to mlock parts of the
> server, but you're finding it difficult to find out which parts exactly
> need to be mlocked.
right. (mlock really su*ks)
> (The conclusion below is from me, not claiming to reflect Tiago's write-up.)
> I'm still convinced that using threads in the X server is a bad idea.
> However, now I at least understand what you're trying to do. I remain
> convinced that a better approach to improving the server's latency is
> to move more stuff to the client side, so that the clients, rather
> than the X server, get swapped out, and banging client authors on the
> head until they stop allocating humonguous server-side structures
> (yes, Firefox, that means you).
While I'm replying this message I see an argument of Lukas saying about
the SMP architectures which is a good point too. So if very well
designed we can separate some pieces of the server and take the
advantage of several cores.
Now a question that I want to know is: what is more desirable to the
kernel efficiently schedule (in terms of context switch, etc): a signal
interruption or another thread?
Thanks for your valuable comments, Juliusz.
C3SL - Centro de Computação Científica e Software Livre
More information about the xorg