X Server: abused or buggy?

[Bill Crawford]

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.