| 1 |
On Fri, Aug 10, 2012 at 11:27 AM, Florian Philipp <lists@×××××××××××.net>wrote: |
| 2 |
|
| 3 |
> Am 10.08.2012 08:56, schrieb Jesús J. Guerrero Botella: |
| 4 |
> > It could be anything. Maybe some orphaned process was running in the |
| 5 |
> > background and leaking ram, or something. It's futile to speculate now |
| 6 |
> > about that. |
| 7 |
> > |
| 8 |
> > Also, the -recently added- "pgo" USE flag could have something to do |
| 9 |
> > with that. Not sure, since I didn't bother to investigate it's true |
| 10 |
> > purpose on firefox. |
| 11 |
> > |
| 12 |
> |
| 13 |
> It does two compilations with a headless firefox benchmark in between. |
| 14 |
> Except of doubling the compilation time, there is little difference in |
| 15 |
> the compilation itself. |
| 16 |
> |
| 17 |
|
| 18 |
It enables profile-based optimizations. The resulting binary is much |
| 19 |
faster, in my subjective experience. |
| 20 |
|
| 21 |
|
| 22 |
> |
| 23 |
> > I really don't think that the kernel has changed in a significant way |
| 24 |
> > in this regard since the latests 2.6.x releases. But I certainly |
| 25 |
> > didn't read *all* the kernel changelogs. |
| 26 |
> > |
| 27 |
> |
| 28 |
> The latest thing of any significance I can think of is the removal of |
| 29 |
> lumpy reclaim in 3.4 which has something to do with reducing memory |
| 30 |
> fragmentation in systems under memory stress. LWN has a subscriber-only |
| 31 |
> article about the change causing performance regressions. From my |
| 32 |
> understanding of the code, I doubt it could cause an improvement in this |
| 33 |
> particular situation. |
| 34 |
> |
| 35 |
|
| 36 |
I honestly think anyone having difficulties with swap should check out the |
| 37 |
vm.swappiness sysctl before looking anywhere else. Setting it to 0 is much |
| 38 |
like removing swap...except you still have the swap space if you actually |
| 39 |
need it. On my work laptop, it looks like it defaults to a value of 60. |
| 40 |
|
| 41 |
-- |
| 42 |
:wq |
Archives