On Thu, 22 Aug 2024 at 14:21, Michal Hocko <mhocko@xxxxxxxx> wrote: > > The reality disagrees because there is a real demand for real GFP_NOFAIL > semantic. By that I do not mean arbitrary requests and sure GFP_NOFAIL > for higher orders is really hard to achieve but kvmalloc GFP_NOFAIL for > anything larger than PAGE_SIZE is doable without a considerable burden > on the MM end. Doable? Sure. Sensible? Not clear. I do not find a single case of that in the kernel. I did find three cases of kvcalloc(NOFAIL) in the nouveau driver and one in erofs. It's not clear that any of them make much sense (or that the erofs one is actually a large allocation). And there's some disgusting noise in hmm_test.c. Irrelevant. Now, this was all from a pure mindless grep, and it didn't take any context into account, so if somebody is building up the gfp flags and not using them directly, that grep has failed. But when you say "reality disagrees", I think you need to point at said reality. Because the *real* reality is that large allocations HAVE ALWAYS FAILED. In fact, with flags like GFP_ATOMIC etc, it will fail very aggressively. Christ, that's what started this whole thread and discussion in the first place. So I think *that* is the reality you need to face: GFP_NOFAIL has never ever been a hard guarantee to begin with, and expecting it to be that is a sign of insanity. It's fundamentally an impossible operation. It really is a "Daddy, daddy, I want a pony" flag. Linus