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 _______________________________________________ xorg mailing list xorg@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg