Re: stable request: mm, page_alloc: actually ignore mempolicies for high priority allocations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 08, 2018 at 09:41:37AM +0000, Mike Manning wrote:
> On 08/11/2018 09:06, Vlastimil Babka wrote:
> > On 11/8/18 10:01 AM, Michal Hocko wrote:
> >> On Thu 08-11-18 08:30:40, Mike Manning wrote:
> >> [...]
> >>> 1) The original commit was not suitable for backport to 4.14 and should
> >>> be reverted.
> >> Yes, the original patch hasn't been marked for the stable tree and as
> >> such shouldn't have been backported. Even though it looks simple enough
> >> it is not really trivial.
> > I think you confused the two patches.
> >
> > Original commit 1d26c112959f ("mm, page_alloc: do not break
> > __GFP_THISNODE by zonelist reset") was marked for stable, especially
> > pre-4.7 where SLAB could be potentially broken.
> >
> > Commit d6a24df00638 ("mm, page_alloc: actually ignore mempolicies for
> > high priority allocations") was not marked stable and is being requested
> > in this thread. But I'm reluctant to agree with this without properly
> > understanding what went wrong.
> 
> Apologies, the original commit was not a backport, but is a fix in 4.14
> for pre-4.7 kernels.
> 
> All I can do from a user perspective is report the problem and the
> fortuitous follow-on commit that resolved the issue in our case. It has
> already taken quite some time to find that the problem was unexpectedly
> due to the kernel upgrade (this failure is a first, we have been running
> these tests for some years going back to the 4.1 kernel), then to go
> through the process of pinpointing the change that caused the issue in
> our case.
> 
> Given that the problem is not manually reproducible, and given that it
> could take a very substantial period of time to understand how the
> change is impacting our scale & performance testing, it seems most
> expedient to backport the 1-line commit that resolves the issue.

Ok, you are asking for this to be added, without really knowing _why_ it
resolves the issue and Michal is asking to know _why_ before acking it,
correct?

So I'll hold off on merging this for now until you all come to some kind
of resolution :)

thanks,

greg k-h




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux