Re: 2.1.99 is less rusty
John Campbell (jcampbel@lynn.ci-n.com)
Sun, 03 May 1998 11:37:40 -0400
> > 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.
>
[...]
> 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'm having the same problems with 2.1.9?. My "benchmark" is simpler and
more subjective than Bill's. I just rebuild the kernel. Under
2.0.[29-33] on this particular machine (a 386-40 with 8M of RAM and 10M
of swap), it takes 3-4 hours to build a kernel. 2.1.9[1-8] couldn't do
it at all - they'd slow down and finally stall out before finishing
(maybe they would have eventually finished... I usually interrupted them
after a few days when the newer kernel came out). 2.1.99 is better - it
actually finished building the kernel, and it only took it about 7.5
hours. As I write this, it's doing the "make modules", and has been
doing so for the last 36 hours.
So, in short, this problem is real, not an artifact of Bill's
benchmarking method, and I agree with Bill that, IMHO, this is a serious
problem that shouldn't be allowed into 2.2. One of Linux's strengths has
been that it could run usefully on very low end hardware, and this
behavior removes that capability. Unfortunately, I don't know enough
kernel hacking to fix this myself, so I can't do much more than provide
another data point here.
---
John Campbell
jcampbel@lynn.ci-n.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu