On Fri 19-07-24 20:28:41, Barry Song wrote: > On Fri, Jul 19, 2024 at 8:01 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > On Fri 19-07-24 19:51:06, Barry Song wrote: > > > On Fri, Jul 19, 2024 at 7:42 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > [...] > > > > It cannot reclaim itself and it cannot sleep to wait for the memory so > > > > NOFAIL semantic is simply impossible. We have put a warning in place to > > > > > > this is still "right" behaviour to retry infinitely at least according > > > to the doc of > > > __GFP_NOFAIL. > > > > I do not agree that implementing busy loop in the kernel is the right > > practice! > > > > > I assume getting new memory by many retries is still > > > possibly some other processes might be reclaiming or freeing memory > > > then providing free memory to this one being stuck. > > > > No, I strongly disagree we should even pretend this is a supported > > allocation strategy. NAK to any attempt to legalize it in some form. > > fare enough. > I am not trying to legitimize it, just explaining what the documentation says. > If it is illegal, we should clearly and firmly state that it is > illegal, rather than > pretending it is legal and returning NULL. This is also wrong. Patches to docuementation are always welcome of course. Please keep in mind that our internal interfaces (something that is not directly exported to the userspace) are not really defensive against users. We do expect some level of reasonable expectations from users. Think about it. GFP_NOWAIT| __GFP_NOFAIL or GDP_ATOMIC|__GFP_NOFAIL is simply impossible with a finite amount of memory. Isn't it? You are literally saying that the request _must not_ fail yet it shouldn't resp. cannot wait for any memory to reclaim if it is not ready for use! With our gfp flag interface we have quite some combinations of flags that we do not support. Do we want to document all of them? -- Michal Hocko SUSE Labs
