hello,
to make things even more strange, the fastest config ever on my box was
an ac10 kernel.
i did make oldconfig for every kernel, so it should be pretty much the
same config every time.
i started testing with ac7 i believe, and that was slow for me ... ac8
was better, i didnot test ac9, ac10 was even much
better. (and solved a mp3 fluent playback problem)
altough there seems not to be any VM change after ac10, things got a bit
slower again after upgrading to ac12 and ac14.
i didnot run ac13 because 13 is the number of bad luck :)
i cannot prove this with benchmarking data, as i have been said that
hdparm -t is 'the bogomips of io' and there is no interactive
performance benchmark i know of (am i wrong?) (maybe we/i need a clear
definition of what 'interactive performance' is, and on what it depends,
its quite subjective now , at least for me.)
keep up the good work
kervel
---------------------------------------------
I've seen this behavior both in ac16 and in ac18. ac4 worked fine (and
was the
fastest kernel I've ever seen on that box)
The box is a 386SX25, with 8MB RAM. The problem is that kswapd eats
99.0% of
the CPU while running dpkg (I also made it happen with X). dpkg uses
10MB of
memory in a particulary awful access pattern (so it swaps a lot).
ac4 was faster than ever, it looked like it wasn't swapping at all
ac16 and ac18 are both awful, dpkg takes an infinite time, all of it
dominated
by kswapd (running top -s and vmstat 1 at the same time). When the
problem
happens everything seems to hang (vmstat lumps some seconds into one, as
I can
see in the interrupt count), no disk activity happens (as if it was lost
thinking what to do next), and on the next update I can see kswapd ate
an awful
amount of CPU (ok, top eats 20% CPU on that box, but why would ac4
remain
pretty responsive when ac16/ac18 stop to a halt?)
It's not zone related (only 8Mb of memory)
To reproduce: use mem=8M (or use a box like mine ;) ) and run dpkg
--list (or
even better, try to install something using dpkg)
I think new VM ideas should always be tested with mem=8M and a dpkg
run...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:35 EST