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
On Tue, 09 Dec 2008 18:15:26 -, Ó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,
Charles Lindsey wrote:
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
We could also investigate using a slab allocator approach for things like
data structures that are a fixed size, to keep them from ending up between
pixmaps, and hopefully reducing fragmentation that way, but that's also more
glibc already does this and you can set a size theshold for mmap
Alan Coopersmith wrote:
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,
2008/12/10 Charles Lindsey [EMAIL PROTECTED]:
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
Alan Coopersmith wrote:
Charles Lindsey wrote:
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
After observing how X used 1.3 GB of RAM, some investigation revealed
that certain application (Okular, a document viewer,
http://okular.kde.org) was causing this memory consumption. It is
creating lots of pixmaps as a way for caching document pages. Opening a
pdf file an scrolling through its
On Tuesday 09 of December 2008, Óscar Fuentes wrote:
After observing how X used 1.3 GB of RAM, some investigation revealed
that certain application (Okular, a document viewer,
http://okular.kde.org) was causing this memory consumption. It is
creating lots of pixmaps as a way for caching
Lubos Lunak wrote:
On Tuesday 09 of December 2008, �scar Fuentes wrote:
After observing how X used 1.3 GB of RAM, some investigation revealed
that certain application (Okular, a document viewer,
http://okular.kde.org) was causing this memory consumption. It is
creating lots of pixmaps as a
Why should it be a KDE bug if the X server is leaking memory? I used to
The KDE app told X to cache all those pixmaps. X is just doing what it
was asked to. The alternative would be that it decided to kill off that
client for being dumb.
___
xorg
Lubos Lunak [EMAIL PROTECTED] writes:
On Tuesday 09 of December 2008, Óscar Fuentes wrote:
After observing how X used 1.3 GB of RAM, some investigation revealed
that certain application (Okular, a document viewer,
http://okular.kde.org) was causing this memory consumption. It is
creating
2008/12/9 Alan Cox [EMAIL PROTECTED]:
Why should it be a KDE bug if the X server is leaking memory? I used to
The KDE app told X to cache all those pixmaps. X is just doing what it
was asked to. The alternative would be that it decided to kill off that
client for being dumb.
There seems to
Alan Cox [EMAIL PROTECTED] writes:
Why should it be a KDE bug if the X server is leaking memory? I used to
The KDE app told X to cache all those pixmaps. X is just doing what it
was asked to. The alternative would be that it decided to kill off that
client for being dumb.
So in your
On Tue, 2008-12-09 at 16:08 +, John Tapsell wrote:
2008/12/9 Alan Cox [EMAIL PROTECTED]:
Why should it be a KDE bug if the X server is leaking memory? I used to
The KDE app told X to cache all those pixmaps. X is just doing what it
was asked to. The alternative would be that it
There seems to be a little bit of confusion here. It seems to me that
Oscar is saying that the memory usage of X remains high even after
closing Okular. Even if Okular told X to cache those pixmaps,
shouldn't they be fully released after Okular quits?
What does his memory allocator do when
Óscar Fuentes wrote:
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?
Depends on the malloc() implementation in your libc and how
On Tue, 9 Dec 2008 16:08:33 +
John Tapsell [EMAIL PROTECTED] wrote:
2008/12/9 Alan Cox [EMAIL PROTECTED]:
Why should it be a KDE bug if the X server is leaking memory? I used to
The KDE app told X to cache all those pixmaps. X is just doing what it
was asked to. The alternative
On Tue, 09 Dec 2008 17:06:04 +0100
Óscar Fuentes [EMAIL PROTECTED] wrote:
Alan Cox [EMAIL PROTECTED] writes:
Why should it be a KDE bug if the X server is leaking memory? I used to
The KDE app told X to cache all those pixmaps. X is just doing what it
was asked to. The alternative
Óscar Fuentes wrote:
Why should it be a KDE bug if the X server is leaking memory? I used to
The KDE app told X to cache all those pixmaps. X is just doing what it
was asked to. The alternative would be that it decided to kill off that
client for being dumb.
So in your opinion
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
21 matches
Mail list logo
