2.0 performed better becase some disk blocks got cached.
2.1 performes worse because the dcache gets plumped but not slimmed.
Your benchmark might not benifit from the dcache because it might not
touch enough files for it to matter.
So even if the dcache was clearing out right you'd still lose a little
time for the 'clearing'.. and your benchmark might not benifit from the
dcache leading to a net slowdown.. :)
On Sat, 2 May 1998, Bill Metzenthen wrote:
>
> Because of the 'mount' problems with the pre-2.1.99 kernels, I didn't
> investigate the effects of the mm changes upon the performance of my
> pitifully low memory machine. With 2.1.99 now released, I forced my way
> around the 'mount' problem and ran my test script. I can report that
> the 2.1.99 kernel appears to be significantly better than other recent
> kernels in the 2.1.xx series, although it is still much worse than
> 2.0.33 in the rusting department...
>
> The results from the test script which I posted to this list are:
>
> $ ./test-compile.sh
> Test gcc compile times.
> Linux version 2.1.99 (root@lorentz) (gcc version 2.8.1) #51 Sat May 2 13:06:32 EST 1998
> gcc takes 35.84 seconds before 'find'
> find /home/sys -print | wc --> find took 23.64 seconds
> 15521 15521 629697
> gcc takes 100.07 seconds after 'find'
> find /home/sys -print | wc --> find took 23.52 seconds
> 15521 15521 629697
> gcc takes 93.48 seconds after 120 second wait
>
>
> To summarise the results so far:
> kernel approx rusting effect
> 2.0.33 38 --> 30 (improves!)
> 2.1.96 37 --> 263
> 2.1.98 43 --> 284
> 2.1.99 36 --> 100
>
> (Note that the results are not precise, there is a random variability
> in the results of perhaps 5% -- but don't quote me because I haven't
> actually gathered statistics...)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu