Re: git: 718d1928f874 - main - LinuxKPI: make linux_alloc_pages() honor __GFP_NORETRY

> Ah I see; that's where the M_WAITOK logic in there comes from.  I was
> wondering about it given others like GFP_KERNEL also being mapped to
> that.  Sometimes that makes me wonder if we should indeed pass the gfp_t
> all the way down to the actual function doing the alloc and only there
> filter and convert rather than doing that earlier in wrapper functions.

I'm pretty sure this is the way to go, as it will allow us to choose a correct behavior in some complicated cases where multiple GFP flags are specified.  Today, some of these flags are converted to M_NOWAIT or M_WAITOK early (and even at compile-time), and we lose the initial request nuances.  GFP flags basically say how many retries and which memory-freeing mechanisms are allowed if the allocation cannot be fulfilled immediately (and sometimes, provide some more context about where the allocation is happening), which doesn't map to our flags directly (except for GFP_NOFAIL, for all other flags we need to use M_NOWAIT and then have various fallback paths).  Although it hasn't happened yet in practice AFAIK, we could even end up with cases where we could both set M_WAITOK and M_NOWAIT (which is an error).

An additional benefit of this approach is to remove the need to recompile LinuxKPI consumers when changing the memory allocation subsystem's behavior.  For example, in this commit, __GFP_RETRY is now defined to be non-zero, but this doesn't affect previously compiled drm-kmod modules.  In other words, to change the behavior, we currently have to change the interface, and although it is a small change, it introduces a bit of friction for testing.

> I know how that feels. I just started looking at something I've done a
> year+ ago completely outside my domain.

:-)

> It clarifies a lot and makes sense and is very helpful!

Thanks.  I think I saw your recent work of yours on LinuxKPI memory allocations, but merely glanced at it.  If you need some support or to exchange ideas, in particular discussing how we should map GFP flags, feel free to contact me.

Regards.

-- 
Olivier Certner