Geert Uytterhoeven writes:
Hi Mikael,
On Sun, Feb 21, 2016 at 6:06 PM, Mikael Pettersson <mikpelinux@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
