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...
-- Cesar Eduardo Barros cesarb@nitnet.com.br cesarb@dcc.ufrj.br- 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:29 EST