On Fri, Aug 10, 2012 at 11:27 AM, Florian Philipp <li...@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
