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

[Mikael Pettersson <mikpelinux@gmail.com>]

Geert Uytterhoeven writes:
 > Hi Mikael,
 > 
 > On Sun, Feb 21, 2016 at 6:06 PM, Mikael Pettersson <mikpelinux@gmail.com> wrote:
 > > Mikael Pettersson writes:
 > >  > Michael Schmitz writes:
 > >  >  > has anyone found a solution to this one?
 > >  >  >
 > >  >  > 3.18-rc5 has kswapd0 hogging the CPU - haven't seen ksoftirqd0 yet.
 > >  >  > Unpacking a large tarball tends to trigger this for me.
 > >  >
 > >  > Alas, no.  I went back to the 3.10.xx kernels and they work Ok for me
 > >  > (they tend to hang during shutdown, but I can live with that).
 > >  >
 > >  > I should do a git bisect...
 > >
 > > 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:
 > 
 > Thanks a lot for doing this!
 > 
 > > # 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.
 > 
 > So git bisect pointed to the merge commit itself, not to any of the commits in
 > the akpm branch?
 > 
 > I redid that merge myself, and the result is the same as ac4de9543aca5.
 > There could still be a semantical merge conflict that cannot be detected by
 > git, though.
 > 
 > Could you try cherry-picking the 36 commits from the akpm branch and
 > bisecting that?
 > I.e.
 >     git checkout 26935fb06ee88f11
 >     git cherry-pick 26935fb06ee88f11..de32a8177f64bc62
 >     git bisect start
 >     git bisect bad
 >     git bisect good 26935fb06ee88f11

I ran these exact commands and restarted my bisection + test loop.

However, git told me it had some 50000+ commits to go through in 16 steps,
so it looks like it selected a much larger range than those 36 commits.

/Mikael