Excessive X server size

[Adam Jackson]

On Wednesday 07 June 2006 14:25, Howard Thomson wrote:

> I assume that the major part of the (my) problem is that, with the X server
> being single-threaded, any single client request that involves paging in
> cached resources will adversely affect all other clients.

Yeah, we're single threaded still.  It's Really Hard to change this, read the 
MTX paper for an idea of how complex it gets.

> I would therefore work on either adding a caching facility, either in an
> associated process (Xcache) or in a separate thread within the X process.
> Any client request needing a resource not immediately available within the
> VM area of the primary thread would be suspended pending a synchronous
> response from the Xcache thread/process. Possibly, event receipt processing
> from Xcache could be in the form of a type of X protocol extension internal
> to that function; in other words Xcache (if a separate process) could
> appear to be a special type of Xclient to minimise changes to the event
> processing loop.

There's another possibility that would give you server-control of pageout 
while preserving the single-threaded semantics, namely, POSIX AIO.  This 
still gets tricky in the case where multiple clients end up blocking on the 
same resource, but you'd still be able to sleep individual clients while the 
kernel handled the disk I/O asynchronously.

> What I was hoping to elicit from my message, was whether anyone was/is
> actually #doing# anything to improve this area. If nobody is, then I may as
> well have a go ....

I don't know of anyone actively working on anything in this space.  It's 
definitely an interesting area of research though.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060607/5b813f85/attachment.pgp>