Kernel scheduling algorithm and X.Org performance

[Alan Cox]

On Mer, 2005-08-31 at 13:45 -0400, Adam Jackson wrote:
> Batching might be nice but I'm really not convinced you need it.  X's 
> effective timeslices are tiny (assuming you avoid software GL) and we rarely 
> handle more than 12 events per Select/Wakeup/Dispatch/Block/Write cycle.  
> Batching events reduces the number of times the server wakes up, but so what.  
> X really is latency-bound, and the time you spend batching is time that the 
> card isn't spending drawing.

Not batching in the X server, batching in the window manager. If you've
got hints as to whether a window understands "update protocol" and
currently is "updating" you can be a lot smarter between the WM and X
about the amount of work you do.

> but you don't get region damage events the way you do with unComposite'd X, 
> so you don't have to do the 70 kajillion round-trips to repaint.  _That_ is 
> what kills us.

Right and X is a model based on the assumption that memory is expensive
and video ram is scarce. We have the video ram and the memory what we
don't have is a way to vanish the latency. Just adding obscene CPU power
simply doesn't work out that way.

There is more RAM on my video card than many of my previous and some of
my current servers.

Alan