Not to thread the X server [was: to thread the X server]

[Tiago Vignatti]

Hi,

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.

right.


> (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.

-- 
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br