X Server: abused or buggy?
billcrawford1970 at gmail.com
Thu Dec 11 04:28:23 PST 2008
On Wednesday 10 December 2008 20:12:19 Glynn Clements wrote:
> If you want to avoid the situation where large amounts of memory are
> allocated for pixmaps, then can't be freed due to other data sharing
> the same memory, you're likely to be better off controlling the
> allocation of the pixmaps than trying to control everything else.
> A more fruitful solution would probably be to use a compacting
> (relocating) allocator for pixmaps (at least for pixel data;
> housekeeping structures don't really matter).
Actually, unless you use a slab allocator, the housekeeping structures matter
just as much; they could still be scattered throughout the memory (and thus
keeping a large chunk of VM allocated, but perhaps not largely in use). The
biggest problem with all long-running processes that do lots of malloc() and
free() like X does - i.e. somewhat randomly - is the memory fragmentation (this
was covered in an episode of Voyager when the EMH went on the blink :o)).
The idea of making allocations relocatable is a good one, and as already noted,
the fact that e.g. pixmaps are almost always referenced indirectly anyway via
an XID, should make it a lot easier.
More information about the xorg