From: Amit Pundir <amit.pundir@linaro.org>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [for-4.9.y] Patch series "use up highorder free pages before OOM"
Date: Mon, 7 Jan 2019 20:08:44 +0530 [thread overview]
Message-ID: <CAMi1Hd2Zo=zK-rYUd9=Fq87QU7qr2rhftJB+CS-OUFWFQD+OPQ@mail.gmail.com> (raw)
In-Reply-To: <20190107114710.GA206194@google.com>
On Mon, 7 Jan 2019 at 17:17, Minchan Kim <minchan@kernel.org> wrote:
>
> On Mon, Jan 07, 2019 at 04:37:37PM +0530, Amit Pundir wrote:
> > Hi Minchan,
> >
> > Kindly review your following mm/OOM upstream fixes for stable 4.9.y.
> >
> > 88ed365ea227 ("mm: don't steal highatomic pageblock")
> > 04c8716f7b00 ("mm: try to exhaust highatomic reserve before the OOM")
> > 29fac03bef72 ("mm: make unreserve highatomic functions reliable")
> >
> > One of the patch from this series:
> > 4855e4a7f29d ("mm: prevent double decrease of nr_reserved_highatomic")
> > has already been picked up for 4.9.y.
> >
> > The original patch series https://lkml.org/lkml/2016/10/12/77 was sort
> > of NACked for stable https://lkml.org/lkml/2016/10/12/655 because no
> > one else reported this OOM behavior on lkml. And the only reason I'm
> > bringing this up again, for stable-4.9.y tree, is that msm-4.9 Android
> > trees cherry-picked this whole series as is for their production devices.
> >
> > Are there any concerns around this series, in case I submit it to
> > stable mailing list for v4.9.y?
>
> Actually, it was not NAK. Other MM guy wanted to backport but I didn't
> intentionally because I didn't see other reports at that time.
>
> However, after that, I got a private email from some other kernel team
> and debugged together. It hit this problem and solved by above patches
> so they backported it.
> If you say Android already check-picked them, it's third time I heard
> the problem(If they really pick those patch due to some problem) since
> we merge those patches into upstream.
> So, I belive it's worth to merge if someone could volunteer.
This is where it gets tricky, Code Aurora cherry-picked these patches
for their Android v4.9.y tree, where they get applied cleanly i.e. no
backport needed. But there is no way to tell if these patches indeed
solved an OOM bug or two for them.
So let me put it this way, is it safe to apply this series on v4.9
kernel? Or should I be wary of regressions?
Regards,
Amit Pundir
>
> Thanks.
next prev parent reply other threads:[~2019-01-07 14:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 11:07 Amit Pundir
2019-01-07 11:07 ` Amit Pundir
2019-01-07 11:47 ` Minchan Kim
2019-01-07 14:38 ` Amit Pundir [this message]
2019-01-07 14:38 ` Amit Pundir
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='CAMi1Hd2Zo=zK-rYUd9=Fq87QU7qr2rhftJB+CS-OUFWFQD+OPQ@mail.gmail.com' \
--to=amit.pundir@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=minchan@kernel.org \
--cc=vbabka@suse.cz \
/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