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
