It seems like anything that hits the inode/dentry caches hard, actually,
and doesn't always happen when freepages (or its 2.4.x equivalent) has
been hit. I had a little applet that malloc'ed and memcpy'ed 1GB of RAM
and exited, which doesn't really help like it did before 2.4.15-pre[56].
It also happens for me a lot more with my 4GB machines, though I have
seen it on my 1GB HIGHMEM boxes as well. If the problem is related to
scanning the cache, perhaps more RAM simply makes it worse.
I'm planning on trying Andrew Morton's patches as soon as I'm able.
Thanks,
-- Ken. brownfld@irridia.com
On Sun, Dec 09, 2001 at 04:51:14PM -0200, Marcelo Tosatti wrote: | | | On Sat, 8 Dec 2001, Ken Brownfield wrote: | | > Just a quick followup to this, which is still a near show-stopper issue | > for me. | > | > This is easy to reproduce for me if I run updatedb locally, and then run | > updatedb on a remote machine that's scanning an NFS-mounted filesystem | > from the original local machine. Instant kswapd saturation, especially | > on large filesystems. | > | > Doing updatedb on NFS-mounted filesystems also seems to cause kswapd to | > peg on the NFS-client side as well. | | Can you reproduce the problem without the over NFS updatedb? | | Thanks | | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to majordomo@vger.kernel.org | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/