Not to thread the X server
Juliusz.Chroboczek at pps.jussieu.fr
Wed Jun 18 15:59:47 PDT 2008
> 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.
Tweaking the scheduler won't help much if there are long-lived
requests. What would be cool would be the ability either to suspend
a request in the middle of its execution and use a block handler to
resume it after servicing input events and other clients, or to have
the main loop delegate the execution of a CPU-bound request to
a thread pool.
> 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?
I don't have any data handy for signals, but I can say for sure that
nptl context switch on a modern Linux kernel on x86 is surprisingly
fast, as fast as the fastest user-space thread libraries. Have a look
at Figure 2 on page 8 of
More information about the xorg