Re: My memory is rusty

Bill Metzenthen (billm@melbpc.org.au)
Sun, 19 Apr 1998 23:49:23 +1000 (EST)


At Sun, 19 Apr 1998 02:25:47 -0400 (EDT), linker@nightshade.ml.org wrote:

> On Sun, 19 Apr 1998, Ragnar Hojland Espinosa wrote:
> > Bill is right, or we are both wrong :) I noticed this too in 2.1.4x ..
> > After a few days of uptime with no intensive processes running, it felt
> > really sluggish due to swapping. Actually, I do remember once that I left
> > the kernel idling on one of the boxen (dx4, 12mb i think), came to have a
> > look in the morning, and this was the behaviour I encountered.
>
> Part of this might have been because of the new dcache code.. Many linux
> systems run a find / overnight and this would swell the dcache.. In the
> earley dcache kernels the dcache was too ram greedy and wouldn't shrink
> well.. :)
>
> Dcache was introduced in .42 I believe..

Bingo! This seems to be the key. Nothing else I have tried to
isolate (time since boot, amount of previous swapping, number of
processes previously created, etc) seems to have much effect.

My test procedure is to time the compilation of one of the kernel
files, then try *whatever*, then time another compilation of the
same file.

With 2.1.96, and *whatever* being `find ~sys | wc` (which produces
the result "15541 15541 630856"), I get:
compile time before: 0:39.20elapsed
compile time after: 4:29.45elapsed
This of course is done immediately after a reboot.

The same test on 2.0.33 gave me:
compile time before: 0:37.46elapsed
compile time after: 0:28.94elapsed
So it seems that the choice of what to cache and how to cache it
worked much better for this particular test in the older kernel.

Someone suggested that I have a look at /proc/slabinfo. I did this
and the only thing which looks significantly changed between the tests
in 2.1.96 are:
-size-128 746 756
+size-128 4368 4396
size-64 91 100
-size-32 593 672
+size-32 4215 4284

I don't know what these are. A quick scan of the sources didn't tell
me a great deal. Can someone interpret this?

The question now is: can the performance in the 2.1.xx kernels be
fixed?

--Bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu