From: Vlastimil Babka <firstname.lastname@example.org> To: Andrew Morton <email@example.com> Cc: firstname.lastname@example.org, email@example.com, Mel Gorman <firstname.lastname@example.org>, Michal Hocko <email@example.com>, David Rientjes <firstname.lastname@example.org>, Joonsoo Kim <email@example.com>, firstname.lastname@example.org Subject: Re: [PATCH] mm, page_alloc: do not break __GFP_THISNODE by zonelist reset Date: Mon, 28 May 2018 11:55:52 +0200 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 05/25/2018 10:48 PM, Vlastimil Babka wrote: > On 05/25/2018 09:43 PM, Andrew Morton wrote: >> On Fri, 25 May 2018 15:08:53 +0200 Vlastimil Babka <email@example.com> wrote: >> >>> we might consider this for 4.17 although I don't know if there's anything >>> currently broken. Stable backports should be more important, but will have to >>> be reviewed carefully, as the code went through many changes. >>> BTW I think that also the ac->preferred_zoneref reset is currently useless if >>> we don't also reset ac->nodemask from a mempolicy to NULL first (which we >>> probably should for the OOM victims etc?), but I would leave that for a >>> separate patch. >> >> Confused. If nothing is currently broken then why is a backport >> needed? Presumably because we expect breakage in the future? Can you >> expand on this? > > I mean that SLAB is currently not affected, but in older kernels than > 4.7 that don't yet have 511e3a058812 ("mm/slab: make cache_grow() handle > the page allocated on arbitrary node") it is. That's at least 4.4 LTS. > Older ones I'll have to check. So I've checked the non-EOL LTS's at kernel.org and: 4.16, 4.14, 4.9 - same as mainline (__GFP_THISNODE broken, but SLAB is OK) 4.4, 4.1, 3.16 - SLAB potentially broken if it makes an ALLOC_NO_WATERMARKS allocation (our 4.4 kernel has backports that extend it to also !ALLOC_CPUSET so it's more likely).
next prev parent reply index Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-25 13:08 Vlastimil Babka 2018-05-25 19:43 ` Andrew Morton 2018-05-25 20:48 ` Vlastimil Babka 2018-05-28 9:55 ` Vlastimil Babka [this message] 2018-05-28 7:21 ` Michal Hocko 2018-05-28 10:00 ` Vlastimil Babka 2018-05-28 8:49 ` Mel Gorman
Reply instructions: You may reply publically 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org email@example.com public-inbox-index lkml Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/ public-inbox