On Fri, Aug 10, 2012 at 11:27 AM, Florian Philipp <lists@binarywings.net>wrote:

> Am 10.08.2012 08:56, schrieb Jesús J. Guerrero Botella:
> > It could be anything. Maybe some orphaned process was running in the
> > background and leaking ram, or something. It's futile to speculate now
> > about that.
> >
> > Also, the -recently added- "pgo" USE flag could have something to do
> > with that. Not sure, since I didn't bother to investigate it's true
> > purpose on firefox.
> >
>
> It does two compilations with a headless firefox benchmark in between.
> Except of doubling the compilation time, there is little difference in
> the compilation itself.
>

It enables profile-based optimizations. The resulting binary is much
faster, in my subjective experience.


>
> > I really don't think that the kernel has changed in a significant way
> > in this regard since the latests 2.6.x releases. But I certainly
> > didn't read *all* the kernel changelogs.
> >
>
> The latest thing of any significance I can think of is the removal of
> lumpy reclaim in 3.4 which has something to do with reducing memory
> fragmentation in systems under memory stress. LWN has a subscriber-only
> article about the change causing performance regressions. From my
> understanding of the code, I doubt it could cause an improvement in this
> particular situation.
>

I honestly think anyone having difficulties with swap should check out the
vm.swappiness sysctl before looking anywhere else. Setting it to 0 is much
like removing swap...except you still have the swap space if you actually
need it. On my work laptop, it looks like it defaults to a value of 60.

-- 
:wq