From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936445AbcLTRic (ORCPT ); Tue, 20 Dec 2016 12:38:32 -0500 Received: from smtprelay0158.hostedemail.com ([216.40.44.158]:32990 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933207AbcLTRi3 (ORCPT ); Tue, 20 Dec 2016 12:38:29 -0500 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::::::::::::::::::::::::::::::::,RULES_HIT:41:355:379:541:599:967:973:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2525:2560:2563:2682:2685:2691:2693:2828:2859:2898:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:5007:6120:6742:7875:9025:10004:10400:10848:11232:11658:11914:12043:12296:12663:12740:12760:12895:13439:13869:14096:14097:14181:14659:14721:21080:21451:30005:30012:30054:30070:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:3,LUA_SUMMARY:none X-HE-Tag: drink58_495bae7a3224c X-Filterd-Recvd-Size: 3822 Message-ID: <1482255502.1984.21.camel@perches.com> Subject: Re: [RFC PATCH] mm: introduce kv[mz]alloc helpers From: Joe Perches To: Michal Hocko , Andrew Morton Cc: linux-mm@kvack.org, Vlastimil Babka , David Rientjes , Mel Gorman , Johannes Weiner , Anatoly Stepanov , LKML , Paolo Bonzini , Mike Snitzer , dm-devel@redhat.com, "Michael S. Tsirkin" , "Theodore Ts'o" , kvm@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, Dave Chinner , Al Viro , Mikulas Patocka Date: Tue, 20 Dec 2016 09:38:22 -0800 In-Reply-To: <20161220135016.GH3769@dhcp22.suse.cz> References: <20161208103300.23217-1-mhocko@kernel.org> <20161213101451.GB10492@dhcp22.suse.cz> <1481666853.29291.33.camel@perches.com> <20161214085916.GB25573@dhcp22.suse.cz> <20161220135016.GH3769@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.22.1-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?