From: Mikael Pettersson <mikpelinux@gmail.com>
To: Mikael Pettersson <mikpelinux@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Michael Schmitz <schmitzmic@gmail.com>,
Andreas Schwab <schwab@linux-m68k.org>,
Linux/m68k <linux-m68k@vger.kernel.org>
Subject: Re: [3.13 regression] kswapd0 and ksoftirqd/0 CPU hogs
Date: Wed, 13 Apr 2016 20:57:08 +0200 [thread overview]
Message-ID: <22286.38532.235484.509180@gargle.gargle.HOWL> (raw)
In-Reply-To: <22235.63087.441832.558429@gargle.gargle.HOWL>
Mikael Pettersson writes:
> 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 :-)
First bisection run completed:
5ee28828d1b5f8d036dc5793be5321dd6f26d344 is the first bad commit
commit 5ee28828d1b5f8d036dc5793be5321dd6f26d344
Author: Michal Hocko <mhocko@suse.cz>
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@google.com: fix memcg-less page reclaim]
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Glauber Costa <glommer@openvz.org>
Cc: Greg Thelen <gthelen@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Ying Han <yinghan@google.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
: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
next prev parent reply other threads:[~2016-04-13 18:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 11:38 [3.13 regression] kswapd0 and ksoftirqd/0 CPU hogs Mikael Pettersson
2014-06-06 11:43 ` Geert Uytterhoeven
2014-06-06 13:11 ` Mikael Pettersson
2014-06-07 13:22 ` Mikael Pettersson
2014-06-11 8:20 ` Mikael Pettersson
2014-06-11 8:45 ` Andreas Schwab
2014-07-01 11:43 ` Mikael Pettersson
2015-03-31 1:16 ` Michael Schmitz
2015-03-31 13:19 ` Mikael Pettersson
2015-04-01 3:08 ` Michael Schmitz
2015-04-01 4:45 ` Finn Thain
2015-04-01 5:21 ` Michael Schmitz
2015-04-06 21:25 ` Michael Schmitz
2015-04-07 0:06 ` Finn Thain
2015-04-07 5:38 ` Michael Schmitz
2016-02-21 17:06 ` Mikael Pettersson
2016-02-21 19:31 ` Michael Schmitz
2016-02-22 10:01 ` Geert Uytterhoeven
2016-03-06 7:21 ` Mikael Pettersson
2016-03-06 8:54 ` Geert Uytterhoeven
2016-03-06 9:20 ` Mikael Pettersson
2016-04-13 18:57 ` Mikael Pettersson [this message]
2016-05-31 4:52 ` Finn Thain
2016-05-31 10:06 ` Mikael Pettersson
2016-05-31 10:21 ` Geert Uytterhoeven
2016-05-31 10:39 ` John Paul Adrian Glaubitz
2016-05-31 10:41 ` Geert Uytterhoeven
2016-06-01 6:36 ` Mikael Pettersson
2015-04-01 16:11 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22286.38532.235484.509180@gargle.gargle.HOWL \
--to=mikpelinux@gmail.com \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@vger.kernel.org \
--cc=schmitzmic@gmail.com \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox