Did I say 2.0 performance was ideal? If so, I didn't mean to and I
didn't mean to imply that I thought so.
> 2.0 performed better becase some disk blocks got cached.
> 2.1 performes worse because the dcache gets plumped but not slimmed.
Maybe, I don't claim to understand why the rusting effect occurs...
> 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.. :)
Hmm, I think that I'd like to avoid the use of the term "benchmark"
here... Perhaps I should re-iterate what the problem is: in later
kernels on a "low" memory (all relative.. my first personal computer
had 4 kbyte of RAM) machine there is an effect where more and more
swapping occurs as one uses the system. Thus after a while the system
is very sluggish. I haven't discovered any way to reverse this
process apart from re-booting. My little test script is claimed to do
nothing more than accelerate this process (relative to "normal" use)
and to provide a rough metric.
I don't know what causes the effect. People have suggested it is due
to either memory fragmentation or cache memory not being freed. I
have looked at the stuff available via /proc and SysRq but it didn't
appear to particularly support either hypothesis.
Linus has announced that the 2.1.xx series will end soon and this is
one problem which I think really should not be knowingly allowed to be
a feature of 2.2.
I don't have the time at the moment to get stuck into solving the
problem myself so I have to hope that the people who have designed the
stuff will fix it (if they feel so inclined and can find the time...).
Cheers,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu