Re: [3.13 regression] kswapd0 and ksoftirqd/0 CPU hogs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sun, 21 Feb 2016, Mikael Pettersson wrote:

I've done two git bisects on this.  The first one was inconclusive 
(pointed to a harmless commit), but the second one ended up with:

# first bad commit: [ac4de9543aca59f2b763746647577302fbedd57e] Merge branch 'akpm' (patches from Andrew Morton)

That's a big pile of VM changes, so I think it could be the culprit.

I think this issue may date back to v2.6.38 or earlier.

The redhat.com bug report was closed in 2012 but Fedora users were still 
seeing the problem after it was supposedly fixed.
  https://bugzilla.redhat.com/show_bug.cgi?id=712019

That page also has a link to the bug report for Ubuntu:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/484045

BTW, I came across this recently: "Rik van Riel pointed out that [the 
kswapd thread] tends to be slow for [the purpose of compaction], and it 
can get stuck in a shrinker somewhere waiting for a lock."
  http://lwn.net/Articles/684611/

Perhaps a stack trace would help to ascertain whether this is the same 
known bug or not (?)

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux