Comment 6 for bug 721896

Revision history for this message
User Unknown (user-unknown) wrote :

I can now confirm that the issue seems unrelated to suspending/resuming. After a continuous uptime of more than 90 hours, my machine just ran into this issue again -- not for the first time within these 90 hours, but for the first time with all previous symptoms and without getting back to normal on its own within a short time.

And this time, it got really bad again, too. Not only one core was maxed out, but most of the time, all four cores were at a 100%, even after closing all running applications (in Gnome), thus the machine was barely usable. Just like back in January.

In case it helps, I attached a log of 'top -i' of the whole thing, dumping its output about every 11 seconds whenever I/O Wait is higher than 5% (if somebody can suggest a better way of tracking this bug, please let me know!). When the issue occurred just now, I wasn't really doing anything different than already the hours before. Sure, I had many applications open and I had only little memory left, but all of these applications had already been open and worked on for a couple of hours prior to the occurrence.

Another thing I noticed when reading Arkadiy's original bug report and his post #4 again: When this issue hits me, in the normal 'top' output, kswapd0 does barely ever show (at least not in the top 17 processes there, sorted by CPU usage). In 'top -i' it appears constantly together with top itself, and sometimes some other processes, mainly 'preload' and 'kondemand/2', flashing by. What eats my CPU is the I/O Wait load on one or multiple cores. As soon as the I/O Wait rises, kswapd0 shows up as idle process (or the other way around...). top always displays it with something between 0% and 4% of CPU and a MEM usage of 0.0%, though.

Whenever this issue occurs, all of top's outputs I've found out so far never display any process as eating all the CPU. So in fact, I don't really know what's going on, and what process is causing it; I only know that kswapd0 always plays some part in it.

So, this might indeed be a different issue than the one Arkadiy reported. Arkadiy, what do you say? Does top show you indeed 100% of CPU usage for kswapd0 itself?