On Tue, 2016-12-20 at 14:50 +0100, Michal Hocko wrote: > 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? Well if Andrew doesn't object again, it should probably be applied. Unless his silence here acts like a pocket-veto. Andrew? Anything to add? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
