On Tue, 09 Dec 2008 18:15:26 -0000, Óscar Fuentes <[EMAIL PROTECTED]> wrote:
> Glynn Clements <[EMAIL PROTECTED]> writes: >>> In other words, is a bug that under this usage mode the memory >>> asigned to X grows monotonically? >> >> No. Most long-lived applications have memory "usage" which grows >> monotonically, for the reasons outlined above. I put "usage" in quotes >> because they won't necessarily be *using* the memory; they'll just >> have it allocated (and swapped out). > > It is my impression that Okular's maintainers think that the X server is > providing a service that their application is using. If this causes an > steadily resource degradation, it's a bug on the service provider. IMO > this point of view makes sense, if and only if using the X server for > massively caching large pixmaps enters within the expected uses of the > service. Even if this is considered abusing the X server, retaining > large portions of memory after the serviced app closes reveals a poor > QoI. Okular's maintainer expected that if heap fragmentantion could > happen for resources stored on the X server, it should perform some sort > of memory compaction for avoiding it. He architectured the app to > exploit the X server caching feature and refuses to consider any other > option, arguing that is the X server who needs to be fixed. > However, let us not dismiss this POV too soon. It is usually argued that an application that suffers from such memory fragmentation should be restarted occasionally (and, given that the Xserver runs in user space, unlike in Windoze, this is not impossible, though perhaps inconvenient in some circumstances). HOWEVER, a compactor within the Xserver should, in principle, be possible, because large Pixmaps and the like are referenced by a serial number rather than by their address in (virtual) memory, and hence it should be possible to relocate them and simply alter the table that accesses them. That might need to be done in conjunction with a specially-written malloc for internal use within the Xserver, but specially-written mallocs are already in use in lots of other contexts. Whether this would, could or should ever actually be done is a separate question, but for sure it should not be dismissed as "impossible". -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg