On Sun 18-08-24 10:55:09, Yafang Shao wrote: > On Sat, Aug 17, 2024 at 2:25 PM Barry Song <21cnbao@xxxxxxxxx> wrote: > > > > From: Barry Song <v-songbaohua@xxxxxxxx> > > > > When users allocate memory with the __GFP_NOFAIL flag, they might > > incorrectly use it alongside GFP_ATOMIC, GFP_NOWAIT, etc. This kind of > > non-blockable __GFP_NOFAIL is not supported and is pointless. If we > > attempt and still fail to allocate memory for these users, we have two > > choices: > > > > 1. We could busy-loop and hope that some other direct reclamation or > > kswapd rescues the current process. However, this is unreliable > > and could ultimately lead to hard or soft lockups, > > That can occur even if we set both __GFP_NOFAIL and > __GFP_DIRECT_RECLAIM, right? No, it cannot! With __GFP_DIRECT_RECLAIM the allocator might take a long time to satisfy the allocation but it will reclaim to get the memory, it will sleep if necessary and it will will trigger OOM killer if there is no other option. __GFP_DIRECT_RECLAIM is a completely different story than without it which means _no_sleeping_ is allowed and therefore only a busy loop waiting for the allocation to proceed is allowed. > So, I don't believe the issue is related > to setting __GFP_DIRECT_RECLAIM; rather, it stems from the flawed > design of __GFP_NOFAIL itself. Care to elaborate? -- Michal Hocko SUSE Labs
