Glynn Clements <[EMAIL PROTECTED]> writes: >> So in your opinion using X as a cache for 500 MB of pixmaps is dumb. I >> tend to agree, but it is reasonable to expect that when the app closes >> and the pixmaps are freed, all that memory is returned to the OS? > > Not really. Most applications just use malloc() and free(), or > something similar.
In this case, the X server does not qualify as an ordinary application. It provides services to other applications and should do so without degrading the quality of the whole system. See below. [snip] >> 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. -- Oscar _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
