Geert Uytterhoeven writes: > Hi Mikael, > > On Sun, Feb 21, 2016 at 6:06 PM, Mikael Pettersson <[email protected]> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
