On Wed 14-12-16 09:59:16, Michal Hocko wrote: > 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? So what are we going to do about this patch? -- 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
