Messages in this thread |  | | | From | Bill Metzenthen <> | | Subject | Re: My memory is rusty | | Date | 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
|  |