Excessive X server size
howard.thomson at dial.pipex.com
Wed Jun 7 11:25:24 PDT 2006
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
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
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
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein
More information about the xorg