Announcing Fedora 7 Test 2 (6.91)

[Adam Jackson]

On Thu, 2007-03-01 at 20:32 +0100, Tomasz Kłoczko wrote:
> Dnia 01-03-2007, czw o godzinie 14:01 -0500, Christopher Blizzard
> napisał(a):
> > That's Gecko, not the X server.  It has pretty aggressive image
> > caching and stores the pixmaps on the server, not in its own memory.
> > If you shut down that process and the X server returns to something
> > sane it's not an X leak.  (It's even arguable that if it doesn't
> > shrink it's still not an X leak but is a fragmented allocator, but
> > that's another discussion.)
> 
> I don't think it is in not only gecko bug because after kill all gecko
> applications amount of memory reserved by X server not back to start
> amount. Also xrestop don't shows anything about allocated big amount of
> memory on X server side for pixmaps.

The memory usage won't always drop back to where it was when you
started, because the allocation arena is shared.  Mozilla's pixmaps will
be interleaved with those of other apps, so the highest-address
allocation not belonging to Mozilla will stick around.

> I'm just kill on my system all gecko applications and amount of memory
> used by X serwer drop down *only* from ~2.2GB to ~1.9GB. If it is not
> ML .. OK. Anyone working on fix X server "fragmented allocator" or so ?

There's nobody working on an allocation repacker for X, no, and it would
be a rather brutal thing to implement.  I started hacking some page-out
code for inactive pixmaps, but never got it working, and it's unclear
that it would help.

> So IMO it is definitely something wrong on X server side. Even it it is
> not my question stays ..  Q: anyone working on fix this ?

It's really hard to fix memory leaks you can't reproduce, and I've left
X and firefox running for months on end without hitting this behaviour.

- ajax