On Tue 13-12-16 14:07:33, Joe Perches wrote: > On Tue, 2016-12-13 at 11:14 +0100, Michal Hocko wrote: > > Are there any more comments or objections to this patch? Is this a good > > start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as > > well in the initial version. > > Did Andrew Morton ever comment on this? > I believe he was the primary objector in the past. > > Last I recollect was over a year ago: > > https://lkml.org/lkml/2015/7/7/1050 Let me quote: : Sigh. We've resisted doing this because vmalloc() is somewhat of a bad : thing, and we don't want to make it easy for people to do bad things. : : And vmalloc is bad because a) it's slow and b) it does GFP_KERNEL : allocations for page tables and c) it is susceptible to arena : fragmentation. : : We'd prefer that people fix their junk so it doesn't depend upon large : contiguous allocations. This isn't userspace - kernel space is hostile : and kernel code should be robust. : : So I dunno. Should we continue to make it a bit more awkward to use : vmalloc()? Probably that tactic isn't being very successful - people : will just go ahead and open-code it. And given the surprising amount : of stuff you've placed in kvmalloc_node(), they'll implement it : incorrectly... : : How about we compromise: add kvmalloc_node(), but include a BUG_ON("you : suck") to it? While I agree with some of those points, the reality really sucks, though. We have tried the same tactic with __GFP_NOFAIL and failed as well. I guess we should just bite the bullet and provide an api which is so common that people keep reinventing their own ways around that, many times wrongly or suboptimally. BUG_ON("you suck") is just not going to help much I am afraid. What do you think Andrew? -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
