Comment 18 for bug 721896

I think what we really need to clarify is what we all mean by
"kswapd0 using/causing 100% CPU". Reading through some of the posts here I
get the feeling that some of us (even me) might not really be talking about
the same thing as some of the others, and therefore might indeed have a
similar but completely different issue from this bug report, as Arkadiy
suggested in #4. Unfortunately, he never got back to me on that question.

When I talk about 100% CPU caused by kswapd0 I mean:
1. A very high I/O Wait state (see output of top, in the line "Cpu(s):"
   the value of "x.x%wa") at or close to 25% (if only one core out of four
   is affected) or even much higher (several of the cores), while User and
   System CPU usage ("x.x%us" and "x.x%sy" in top) is rather negligible.
2. In these cases, kswapd0 can only ever be noticed as – the only –
   uninterruptable or idle process, e.g. via 'ps auxww' or 'top -i', while
   in top's normal output, neither kswapd0 nor any other process would
   really stand out for its unusually high CPU consumption.
3. According to 'free', there would still be plenty of physical memory free,
   and also, at least at the time this issue starts, mounted swap space
   (doesn't matter whether both swap partition *and* /dev/ramzswap0 drive
   are currently swapped on or only one of them - check with 'swapon -s')
   would barely be in use, or no swap space would be swapped on at all.

So, who is talking about the exactly same thing?
And more importantly, Arkadiy, did you?