Excessive X server size

[Howard Thomson]

Hi Adam,

Thanks for responding. I was beginning to think that my message had 
disappeared into the proverbial black-hole !

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.

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.

I had to do some similar kludges to my Atari ST port of the X server, due to 
the fact that simultaneous reception, in the case of a screen refresh, of 
TCP/IP expose event responses caused the TCP subsystem to die due to memory 
exhaustion.

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

As you say, the existing code would have to be adapted to do some LRU evicting 
of resources to permit the creation of new resources within the basic VM 
footprint, but I think it should be doable (famous last words ...)

On Wednesday 07 June 2006 18:35, you wrote:
> On Monday 05 June 2006 13:16, Howard Thomson wrote:
> > I am considering getting involved again, as I am dissatisfied, to put it
> > mildly, with the fact that my current system (see below) manages to
> > achieve a time to unlock the current session of approaching 5 (five!)
> > minutes, mainly due, presumably, to the massively excessive VM size of
> > the X server process.
> >
> > A short time ago, plus 5 minutes to get a response from the system, KDE
> > System Guard Process Table listed my X server as:
> >  2.5Gb VmSize
> >  1.7Gb VmRss
> >
> > With the X server still being, as I understand it, single threaded, this
> > delay must be caused by thrashing to/from swap, and prior to my
> > dedicating a whole 80Gb HDD to swap used to crash my machine with
> > monotonous regularity, especially prior to my move to X86-64.
> >
> > Is anyone working on solutions to this problem area, or am I missing some
> > configuration settings or later fixes to alleviate such symptoms ?
> >
> > The most guilty client culprit is currently Opera, although both
> > Konqueror and Firefox managed to achieve similar effects prior to my
> > moving to Opera.
>
> This _is_ the problem.  The server is largely innocent; it can only do what
> apps ask it to do, and when apps ask it to hold on to large quantities of
> resources...  Granted we probably have some fragmentation problems too, but
> I expect they're second-order at most.
>
> One idea I've kicked around for a while is teaching the fb layer how to
> swap out pixmaps directly, since it knows better than the kernel which
> pixmaps are active.  It'd be slightly tricky.
>
> - ajax

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein