Mikael Pettersson writes:
Geert Uytterhoeven writes:
> Hi Mikael,
>
> On Sun, Mar 6, 2016 at 8:21 AM, Mikael Pettersson <mikpelinux@xxxxxxxxx> wrote:
> > Geert Uytterhoeven writes:
> > > On Sun, Feb 21, 2016 at 6:06 PM, Mikael Pettersson <mikpelinux@xxxxxxxxx> 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 :-)
First bisection run completed:
5ee28828d1b5f8d036dc5793be5321dd6f26d344 is the first bad commit
commit 5ee28828d1b5f8d036dc5793be5321dd6f26d344
Author: Michal Hocko <mhocko@xxxxxxx>
Date: Thu Sep 12 15:13:26 2013 -0700
memcg: enhance memcg iterator to support predicates
The caller of the iterator might know that some nodes or even subtrees
should be skipped but there is no way to tell iterators about that so the
only choice left is to let iterators to visit each node and do the
selection outside of the iterating code. This, however, doesn't scale
well with hierarchies with many groups where only few groups are
interesting.
This patch adds mem_cgroup_iter_cond variant of the iterator with a
callback which gets called for every visited node. There are three
possible ways how the callback can influence the walk. Either the node is
visited, it is skipped but the tree walk continues down the tree or the
whole subtree of the current group is skipped.
[hughd@xxxxxxxxxx: fix memcg-less page reclaim]
Signed-off-by: Michal Hocko <mhocko@xxxxxxx>
Cc: Balbir Singh <bsingharora@xxxxxxxxx>
Cc: Glauber Costa <glommer@xxxxxxxxxx>
Cc: Greg Thelen <gthelen@xxxxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
Cc: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
Cc: Michel Lespinasse <walken@xxxxxxxxxx>
Cc: Tejun Heo <tj@xxxxxxxxxx>
Cc: Ying Han <yinghan@xxxxxxxxxx>
Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
:040000 040000 46799adf458e8a2db998ef099dae907af03e1595 29638de8593a98add32f56fb9aea16cd8227f6a4 M include
:040000 040000 27e4202d2f2a785e35454ef93e75919997219130 8c5973443d35e65eb88a0155b2c78bf90c650a21 M mm
I'll reset and re-bisect with the known bad points pre-seeded.
/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
