On Fri, Jul 19, 2024 at 8:40 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > 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? I don't see why not, at least for GFP_NOFAIL, because its current documentation strongly states that it will loop infinitely even if it can't get memory. It never mentions the potential for a NULL return. Not everyone is an MM expert, especially considering we have hundreds of driver developers who are simply calling APIs. We shouldn't rely on specialized MM knowledge to implement a driver. And I believe that even most MM experts have no idea when GFP_NOFAIL will fail. This is so bad to keep it as is. > -- > Michal Hocko > SUSE Labs Thanks Barry
