Hi Mikael,
On Tue, May 31, 2016 at 12:06 PM, Mikael Pettersson
<[email protected]> wrote:
> Finn Thain writes:
> > On Sun, 21 Feb 2016, Mikael Pettersson wrote:
> > > 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:
> > >
> > > # 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.
> >
> > I think this issue may date back to v2.6.38 or earlier.
> >
> > The redhat.com bug report was closed in 2012 but Fedora users were still
> > seeing the problem after it was supposedly fixed.
> > https://bugzilla.redhat.com/show_bug.cgi?id=712019
> >
> > That page also has a link to the bug report for Ubuntu:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/484045
> >
> > BTW, I came across this recently: "Rik van Riel pointed out that [the
> > kswapd thread] tends to be slow for [the purpose of compaction], and it
> > can get stuck in a shrinker somewhere waiting for a lock."
> > http://lwn.net/Articles/684611/
> >
> > Perhaps a stack trace would help to ascertain whether this is the same
> > known bug or not (?)
> >
> > --
>
> FWIW, my latest round(s) of bisects identified the following:
>
> fdbadebec27cc92358ed4f593e8763cf10b82687 is the first bad commit
> commit fdbadebec27cc92358ed4f593e8763cf10b82687
> Author: Li Zefan <[email protected]>
> Date: Thu Sep 12 15:13:19 2013 -0700
>
> memcg: remove redundant code in mem_cgroup_force_empty_write()
>
> vfs guarantees the cgroup won't be destroyed, so it's redundant to get a
> css reference.
>
> Signed-off-by: Li Zefan <[email protected]>
> Acked-by: Michal Hocko <[email protected]>
> Cc: KAMEZAWA Hiroyuki <[email protected]>
> Cc: Johannes Weiner <[email protected]>
> Cc: Tejun Heo <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
>
> :040000 040000 1f6b5b056995067c7c60e6f87e9cd1f181e8fbeb
> ea29d63e70ce2320e144fac7b157a146d41360bf M mm
>
> This appears to be the first commit in the merge (git bisect refuses to
> bisect before it), so either it's it or the problem predates the merge.
That's upstream commit c33bd8354f3a3bb26a98d2b6bf600b7b35657328?
Well done! Looks indeed like a suspect for the behavior you're seeing.
I suppose you will follow up with the mm people?
Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
