Re: [PATCH] mm,page_alloc: apply gfp_allowed_mask before the first allocation attempt.

[Michal Hocko <mhocko@suse.com>]

On Mon 04-09-17 10:22:59, Vlastimil Babka wrote:
> On 09/01/2017 05:16 PM, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> >> On Fri 01-09-17 23:11:31, Tetsuo Handa wrote:
> >>> We are by error initializing alloc_flags before gfp_allowed_mask is
> >>> applied. Apply gfp_allowed_mask before initializing alloc_flags so that
> >>> the first allocation attempt uses correct flags.
> >>
> >> It would be worth noting that this will not matter in most cases,
> >> actually when only the node reclaim is enabled we can misbehave because
> >> NOFS request for PM paths would be ignored.
> 
> Hmm don't we have the same problem with the god-damned node reclaim by
> applying current_gfp_context() also only after the first attempt? But
> that would be present since 21caf2fc1931b.
> Hm, actually no, because reclaim calls current_gfp_context() by itself.
> Good.

Yes.

> Maybe reclaim should also do the gfp_allowed_mask filtering?

I would rather not spread it more than it is really needed.

> I wonder how safe the pm_restrict_gfp_mask() update is when an
> allocation is already looping in __alloc_pages_slowpath()...

It will be broken

> What exactly are your ideas to get rid of gfp_allowed_mask, Michal?

Well I planned to actually examine why do we need it in the first place
and whether the original intention still applies and if yes then replace
it by memalloc_noio_save. It would still be proken in a similar way you
pointed out but something tells me that it is just obsolete.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>