[lkml]   [1998]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.1.99 is less rusty
According to
> Well.. Depending on your test new kernels might always be 'slower' after
> the find.. This is still 'too slow' but the 2.0 performance might no have
> been as ideal as you think.

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...).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.050 / U:0.304 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site