From: Mike Manning <mmanning@vyatta.att-mail.com>
To: Vlastimil Babka <vbabka@suse.cz>, stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
linux-mm <linux-mm@kvack.org>
Subject: Re: stable request: mm, page_alloc: actually ignore mempolicies for high priority allocations
Date: Thu, 8 Nov 2018 08:30:40 +0000 [thread overview]
Message-ID: <fa553398-f4bf-3d57-376b-94593fb2c127@vyatta.att-mail.com> (raw)
In-Reply-To: <08ae2e51-672a-37de-2aa6-4e49dbc9de02@suse.cz>
On 08/11/2018 07:54, Vlastimil Babka wrote:
> +CC linux-mm
>
> On 11/7/18 6:33 PM, Mike Manning wrote:
>> Hello, Please consider backporting to 4.14.y the following commit from
>> kernel-net-next by Vlastimil Babka [CC'ed]:
>>
>> d6a24df00638 ("mm, page_alloc: actually ignore mempolicies for high
>> priority allocations") It cherry-picks cleanly and builds fine.
>>
>> The reason for the request is that the commit 1d26c112959f ("mm,
>> page_alloc:do not break __GFP_THISNODE by zonelist reset") that was
>> previously backported to 4.14.y broke some of our functionality after we
>> upgraded from an earlier 4.14 kernel without the fix.
> Well, that's very surprising! Could you be more specific about what
> exactly got broken?
Thank you for your reply. I agree, we were also very surprised when
bisecting our updated 4.14 kernel, as this change is apparently
completely unrelated to our application running in userspace. But the
problem was 100% reproducible on a baremetal setup running automated
performance multi-stream testing, so only seen under load. With the fix
reverted from the 4.14 kernel, the problem went away, and this is with
many repeated runs (the load test is part of a suite that is
automatically run quite a few times every day, and this test was failing
since the upgrade).
>
>> The reason this is
>> happening is not clear, with this commit only found by bisect.
>> Fortunately the requested commit resolves the issue.
> I would like to understand the problem first, because I currently can't
> imagine how the first commit could break something and the second fix it.
I agree, but from an empirical point of view, 2 options present:
1) The original commit was not suitable for backport to 4.14 and should
be reverted.
2) For the same reason that the original commit was suitable for
backport to 4.14, the requested commit should also be backported.
>> Best Regards,
>>
>> Mike Manning
>>
next prev parent reply other threads:[~2018-11-08 8:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a66fb268-74fe-6f4e-a99f-3257b8a5ac3b@vyatta.att-mail.com>
2018-11-08 7:54 ` Vlastimil Babka
2018-11-08 8:30 ` Mike Manning [this message]
2018-11-08 9:01 ` Michal Hocko
2018-11-08 9:06 ` Vlastimil Babka
2018-11-08 9:11 ` Michal Hocko
2018-11-08 9:41 ` Mike Manning
2018-12-28 10:49 ` Greg Kroah-Hartman
2018-11-08 9:32 ` Vlastimil Babka
2018-11-08 10:01 ` Mike Manning
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=fa553398-f4bf-3d57-376b-94593fb2c127@vyatta.att-mail.com \
--to=mmanning@vyatta.att-mail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=stable@vger.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