Just an observation : when I updated Libre Office & Firefox this week,
neither compile used swap (I have 4 GB RAM);
OTOH when I did them the previous time, both did use swap;
the total time & the HDD usage remained almost the same.
In between, I updated the Kernel 3.0.0 -> 3.4.0 ,
but made no other changes in config files etc.

Does anyone have thoughts re the effect of kernel versions on swapping ?

--
========================,,======================== ====================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Am 07.08.2012 07:02, schrieb Philip Webb:
> Just an observation : when I updated Libre Office & Firefox this week,
> neither compile used swap (I have 4 GB RAM);
> OTOH when I did them the previous time, both did use swap;
> the total time & the HDD usage remained almost the same.
> In between, I updated the Kernel 3.0.0 -> 3.4.0 ,
> but made no other changes in config files etc.
>
> Does anyone have thoughts re the effect of kernel versions on swapping ?
>

Did Firefox ever actually need to swap? Here it does a fair share of
disk I/O (some python script?) but never actually needs lots of memory.

With Libre Office, it could be their recent code cleaning effort. They
removed large amounts of cruft.

120808 Florian Philipp wrote:
> Am 07.08.2012 07:02, schrieb Philip Webb:
>> Just an observation : when I updated Libre Office & Firefox this week,
>> neither compile used swap (I have 4 GB RAM);
>> OTOH when I did them the previous time, both did use swap;
>> the total time & the HDD usage remained almost the same.
>> In between, I updated the Kernel 3.0.0 -> 3.4.0 ,
>> but made no other changes in config files etc.
> Did Firefox ever actually need to swap? Here it does a fair share
> of disk I/O (some python script?) but never actually needs lots of memory.
> With Libre Office, it could be their recent code cleaning effort.
> They removed large amounts of cruft.

Sorry, perhaps I didn't make it clear enough:
I'm refering to the process of compiling the pkgs via Portage,
not to using them after they have been installed.
Both packages used noticeably less memory during the compile stage
on the latest occasion in contrast to the previous Emerges.

--
========================,,======================== ====================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Am 08.08.2012 11:33, schrieb Philip Webb:
> 120808 Florian Philipp wrote:
>> Am 07.08.2012 07:02, schrieb Philip Webb:
>>> Just an observation : when I updated Libre Office & Firefox this week,
>>> neither compile used swap (I have 4 GB RAM);
>>> OTOH when I did them the previous time, both did use swap;
>>> the total time & the HDD usage remained almost the same.
>>> In between, I updated the Kernel 3.0.0 -> 3.4.0 ,
>>> but made no other changes in config files etc.
>> Did Firefox ever actually need to swap? Here it does a fair share
>> of disk I/O (some python script?) but never actually needs lots of memory.
>> With Libre Office, it could be their recent code cleaning effort.
>> They removed large amounts of cruft.
>
> Sorry, perhaps I didn't make it clear enough:
> I'm refering to the process of compiling the pkgs via Portage,
> not to using them after they have been installed.
> Both packages used noticeably less memory during the compile stage
> on the latest occasion in contrast to the previous Emerges.
>

No, you made yourself clear. I didn't. I meant the compiling, too.

Am Dienstag, 7. August 2012, 01:02:29 schrieb Philip Webb:
> Just an observation : when I updated Libre Office & Firefox this week,
> neither compile used swap (I have 4 GB RAM);
> OTOH when I did them the previous time, both did use swap;
> the total time & the HDD usage remained almost the same.
> In between, I updated the Kernel 3.0.0 -> 3.4.0 ,
> but made no other changes in config files etc.
>
> Does anyone have thoughts re the effect of kernel versions on swapping ?

different kernel versions are more or less swap happy. Has always been the
case.
(I remember 2.2.10 - extreme swapping even with lots of ram... and 2.2.14 - no
swapping at all...)

--
#163933

http://people.gnome.org/~michael/blog/2012-08-08-libreoffice-3-6-0.html


As someone said, a lot of legacy code is being removed/cleaned/simplyfied.


Kernel could be an issue when it comes to swappiness, but not when it comes to the amount of ,memory that a given version of $CC will use to compile a given package, provided that $HARDWARE and $CFLAGS are constant.

120809 Jesús J. Guerrero Botella wrote:
> http://people.gnome.org/~michael/blog/2012-08-08-libreoffice-3-6-0.html

Yes, I read that c 2 hr ago (smile).

> As someone said, a lot of legacy code is being removed/cleaned/simplified.

It doesn't explain why I saw the same effect with Firefox 14.1 :
perhaps there's been some code-cleaning there too.

> Kernel could be an issue when it comes to swappiness,
> but not when it comes to the amount of memory
> a given version of $CC will use to compile a given package,
> provided that $HARDWARE and $CFLAGS are constant.

That's what I suspected, but wasn't sure about.

Any other thoughts are welcome.

--
========================,,======================== ====================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

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.

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.

--
Jesús Guerrero Botella

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.

> 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.

Regards,
Florian Philipp

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