On Mon 28-05-18 10:23:07, Shakeel Butt wrote: > On Mon, May 28, 2018 at 2:11 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > Though is there a precedence where the broken feature is not fixed > because an alternative is available? Well, I can see how breaking GFP_NOFAIL semantic is problematic, on the other hand we keep saying that kmem accounting in v1 is hard usable and strongly discourage people from using it. Sure we can add the code which handles _this_ particular case but that wouldn't make the whole thing more usable I strongly suspect. Maybe I am wrong and you can provide some specific examples. Is GFP_NOFAIL that common to matter? In any case we should balance between the code maintainability here. Adding more cruft into the allocator path is not free. -- Michal Hocko SUSE Labs
