(Please Cc replies to me) Hi, Shortly after suspending with Software Suspend 2 in 2.6.11-rc1, kswapd begins to act most strangely. I can't test with the vanilla swsusp, as it Oopses on suspend. Using Software Suspend 2, I only need to initiate the suspend then abort (which gets far enough to call shrink_all_memory which I believe might be what triggers it). Vanilla swsusp also calls shrink_all_memory(10000) so I imagine it would probably suffer the same bug if it worked. The machine has 1GB of RAM, kernel is using 4G highmem. Before suspending, only about 200MB of memory is used. The machine comes back fine, and all is well, until... Within a minute or less, kswapd will try to flush out as much data to disk as it possibly can, making the machine unusable in process. Of the 200MB of memory, it flushes 170MB out to swap, leaving 30MB in RAM. While it's doing this, kswapd's call trace looks like: [schedule_timeout+94/176] schedule_timeout+0x5e/0xb0 [io_schedule_timeout+17/32] io_schedule_timeout+0x11/0x20 [blk_congestion_wait+110/144] blk_congestion_wait+0x6e/0x90 [balance_pgdat+572/912] balance_pgdat+0x23c/0x390 [kswapd+221/256] kswapd+0xdd/0x100 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 I'm guessing it stops when it can't possibly flush out any more memory, and goes back to idling: [kswapd+171/224] kswapd+0xab/0xe0 [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 >From here on, the machine acts as normal. I can swapoff and swapon again to flush things back into memory and life is happy. If I disable the swap partition after resuming, instead of flushing stuff out to swap, kswapd will simply alternate between R and D states, consuming CPU and making the machine sluggish. I let it sit there for a few minutes like this, then turned swap back on, at which point it did the same thing as above (flush everything out to swap). If I set /proc/sys/vm/swappiness to 0, it only flushes about 30 or 40MB out to swap before returning to normal, but it still does it. (swappiness is defaulting to 60). I reverted the changes to mm/vmscan.c between 2.6.10 and 2.6.11-rc1 with the attached patch (applies forwards over the top of 2.6.11-rc1), and I no longer get any kswapd weirdness. Is there something in here misbehaving? I'm happy to provide any more info, or test any patches. Thanks in advance, Bernard. -- Bernard Blackham