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 t
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,
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
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 imposs
> 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
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, thoug
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
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
Ó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
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 a
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 a
Ó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 fr
> 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 wh
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 th
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
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 se
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
>> cr
> 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 mai
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 pixma
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 doc
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 page
21 matches
Mail list logo
