> Would people who use small-memory machines and see the rusting effect
> and have a good feel for it please try out the new pre-110-3 patch on
> ftp.kernel.org to see whether it looks better.
The effect of the pre-patches upon the "rusting" effect is given at
the end of this message. It does indeed reduce the magnitude of the
effect, but doesn't remove it. However, it is by far the least
rusting affected kernel since the effect appeared.
To put things into perspective again, 2.1.110-pre3 would probably be
acceptable to most users with low memory machines because the rusting
effect (when triggered) with this kernel appears to be small enough
for it to often go un-noticed among the normal variability of
performance. It would be noticed when triggered in a setup where
performance is monitored, but perhaps such setups are unlikely...
I can't make a meaningful comment on how the kernel "feels" because
the broken console driver makes it "feel" terrible for monochrome
adapters!
Bill Metzenthen
--------------------------------------------------------------------------
Rusting Effect Update.
------- ------ -------
[For those new to the effect, somewhere in the 2.1.xx kernel series
my low memory machine (8Mbyte) began to get sluggish after being
used for some time, due to lots of swapping. This excessive swapping
is reliably triggered by doing a 'find' on a directory which has lots
of files (a few tens of thousands) in sub-directories, etc. My test
consists of measuring the time taken to compile one of the kernel files
before and after doing such a find (fresh after re-booting).]
The results so far:
kernel approx rusting effect (compile time in
seconds before and after 'find')
2.0.33 38 --> 30 (improves!)
2.1.96 37 --> 263
2.1.98 43 --> 284
2.1.99 36 --> 100
2.1.100 38 --> 121
2.1.101 47 --> 152
2.1.102 48 --> 150
2.1.103 53 --> 168
2.1.106 57 --> 209
2.1.108 54 --> 200
2.1.109 51 --> 273
2.0.33 42 --> 34
2.1.109 46 --> 153 (1: 20 40 60 > freepages)
--> 108 (1: 2 min)
--> 75 (1: 15 min)
--> 80 (1: 60 min)
2.1.109 40 --> 117 (2: 20 25 30 > freepages)
--> 90 (2: 2 min)
2.1.40 46 --> 42
2.1.64 56 --> 600
2.1.109patched 55 --> 192 (3)
2.1.110pre3 39 --> 51
--> 61 (4: 2 min)
--> 51 (4: 25 min)
Notes: (1) mm parameters set with: echo "20 40 60" > /proc/sys/vm/freepages
and then test repeated after the shown delays without rebooting
between.
(2) mm parameters set with: echo "20 25 30" > /proc/sys/vm/freepages
(3) Patch by Andi Kleen <ak@muc.de>.
(4) Test repeated after the shown delays without rebooting. There
appears to be no significant recovery effect.
Don't read too much into the precise figures. These results were
obtained over a period of months, during which various things have
changed (such as libraries, probably the compiler, etc). The first
2.0.33 result was obtained on 25 April, the last on 18th July.
All of the later kernels <= 2.1.109 show some (but not full) recovery
over time.
-- ----------------------------------------------------------------------------- Bill Metzenthen | See http://www.suburbia.net/~billm/ for information billm@melbpc.org.au | on an 80x87 FPU emulator, using floating point billm@suburbia.net | (particularly on Linux), and code for manipulating Melbourne, Australia | the floating point environment on 80x86 Linux. ------------------------------------------------------------------------------ To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html