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

[Mikael Pettersson <mikpelinux@gmail.com>]

Geert Uytterhoeven writes:
 > Hi Mikael,
 > 
 > On Sun, Mar 6, 2016 at 8:21 AM, Mikael Pettersson <mikpelinux@gmail.com> wrote:
 > > Geert Uytterhoeven writes:
 > >  > On Sun, Feb 21, 2016 at 6:06 PM, Mikael Pettersson <mikpelinux@gmail.com> wrote:
 > >  > > # 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.
 > 
 > Are you sure you did exactly that?
 > 
 > $ git checkout 26935fb06ee8
 > [...]
 > $ git cherry-pick 26935fb06ee88f11..de32a8177f64bc62
 > [...]
 > $ git bisect start
 > $ git bisect bad
 > $ git bisect good 26935fb06ee88f11
 > Bisecting: 17 revisions left to test after this (roughly 4 steps)
 > [8969e7b3b3302ea668d300d0fa593108003b908b] mm: memcg: do not trap
 > chargers with full callstack on OOM
 > $

Yes, I copy-pasted those commands exactly.  However, git got confused
because I didn't 'git bisect reset' first.  Now it has the correct
range to bisect :-)

/Mikael