Re: 2.6.10-rc3: kswapd eats CPU on start of memory-eating task

From: Nick Piggin
Date: Thu Dec 16 2004 - 03:16:22 EST

Nick Piggin wrote:
Voluspa wrote:

Earlier today I wrote:

I find no problem when blender is the sole (large) application, but when a
distributed computing client is running in the background the reported


surface. I use for protein folding. It runs
with a default of nice 19 and sucks up every free CPU cycle. I've never
seen it interfere with anything prior to this swap issue - been running
it since 2000.

More testing done to find the breaking point. Running the folding client and blender: is the last kernel without _any_ swapping problem (no screen freezes etc)
| 2.6.9-rc1 and three -bk forward have oopses and loss of keyboard in X. Can't test them.
2.6.9-rc1-bk4 is the first functional kernel where the freezes show up.

So it is a real regression.

Can you turn on magic sysrq in the kernel hacking menu, and press
alt+sysrq+m a few times while kswapd is using lots of memory, please?

Then run `dmesg -s 1000000 > dmesg.out`, and send the dmesg over,

By the way, I think the only relevant VM patches that went in between
2.6.8 and 2.6.9-rc2 are the following:

[PATCH] vm: writeout watermark tuning

[PATCH] vm: alloc_pages watermark fixes

[PATCH] alloc_pages priority tuning

The first one shouldn't do much, and the last two should definitely
be improving things rather than anything else, because they cause
kswapd to properly start freeing in the background rather than force
the app to do the memory freeing itself.

This did expose a couple of bugs in kswapd, which were since fixed,
but are not in the 2.6.9-rc1-bk4 kernel.

So please, do the sysrq+m traces with a 2.6.10-rc3 kernel. Thanks.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at