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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
