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. _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
