Re: [PATCH] MM: discard __GFP_ATOMIC

[Michal Hocko]

On Tue 23-11-21 15:33:19, Neil Brown wrote:
[...]
> "ALLOC_HARDER" is a question of "can I justify imposing on other threads
> by taking memory that they might want".  Again there may be different
> reasons, but they will not always align with the first set.
> 
> With my patch there is still a difference between ALLOC_HIGH and
> ALLOC_HARDER, but not much.
> __GFP_HIGH combined with __GFP_NOMEMALLOC - which could be seen as "high
> priority, but not too high" delivers ALLOC_HIGH without ALLOC_HARDER.
> It may not be a useful distinction, but it seems to preserve most of
> what I didn't want to change.

I am not sure this is really a helpful distinction. I would even say that
an explicit use of __GFP_NOMEMALLOC | __GFP_HIGH is actively confusing
as that would mean that you do not allow access to reserves while you
want to dip into them anyway.

Anyway, I still think that ALLOC_HARDER should stay under control of the
allocator as a heuristic rather being imprinted into gfp flags
directly. Having two levels of memory reserves access is just too
complicated for users and I wouldn't be surprised if most callers would
just consider their usecase important enough to justify as much reserves
as possible.

Allocation from an interrupt context sounds like a good usecase for
ALLOC_HARDER. I am not sure about rt_task one but that one can be
reasoned about as well. All/most __GFP_HIGH allocations just look like
an overuse and conflation of the two modes. Both these were the primary
usecase for ALLOC_HARDER historically we just tried to find a way how to
express the former by gfp flags.
-- 
Michal Hocko
SUSE Labs