All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Anatoly Stepanov <astepanov@cloudlinux.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	dm-devel@redhat.com, "Michael S. Tsirkin" <mst@redhat.com>,
	Theodore Ts'o <tytso@mit.edu>,
	kvm@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-security-module@vger.kernel.org,
	Dave Chinner <david@fromorbit.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: [RFC PATCH] mm: introduce kv[mz]alloc helpers
Date: Tue, 20 Dec 2016 09:38:22 -0800	[thread overview]
Message-ID: <1482255502.1984.21.camel@perches.com> (raw)
In-Reply-To: <20161220135016.GH3769@dhcp22.suse.cz>

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?


WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Anatoly Stepanov <astepanov@cloudlinux.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	dm-devel@redhat.com, "Michael S. Tsirkin" <mst@redhat.com>,
	Theodore Ts'o <tytso@mit.edu>,
	kvm@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-security-module@vger.kernel.org,
	Dave Chinner <david@fromorbit.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: [RFC PATCH] mm: introduce kv[mz]alloc helpers
Date: Tue, 20 Dec 2016 09:38:22 -0800	[thread overview]
Message-ID: <1482255502.1984.21.camel@perches.com> (raw)
In-Reply-To: <20161220135016.GH3769@dhcp22.suse.cz>

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?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-12-20 17:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-08 10:33 [RFC PATCH] mm: introduce kv[mz]alloc helpers Michal Hocko
2016-12-08 10:33 ` Michal Hocko
2016-12-08 10:33 ` Michal Hocko
2016-12-08 13:00 ` David Hildenbrand
2016-12-08 13:00   ` David Hildenbrand
2016-12-08 13:51   ` Michal Hocko
2016-12-08 13:51     ` Michal Hocko
2016-12-09  1:44 ` Dave Chinner
2016-12-09  1:44   ` Dave Chinner
2016-12-09  2:00   ` Al Viro
2016-12-09  2:00     ` Al Viro
2016-12-09  6:22     ` Michal Hocko
2016-12-09  6:22       ` Michal Hocko
2016-12-09  6:38       ` Al Viro
2016-12-09  6:38         ` Al Viro
2016-12-09  6:51         ` Michal Hocko
2016-12-09  6:51           ` Michal Hocko
2016-12-09  6:18   ` Michal Hocko
2016-12-09  6:18     ` Michal Hocko
2016-12-13 10:14 ` Michal Hocko
2016-12-13 10:14   ` Michal Hocko
2016-12-13 20:55   ` Andreas Dilger
2016-12-14  9:05     ` Michal Hocko
2016-12-14  9:05       ` Michal Hocko
2016-12-13 22:07   ` Joe Perches
2016-12-13 22:07     ` Joe Perches
2016-12-14  8:59     ` Michal Hocko
2016-12-14  8:59       ` Michal Hocko
2016-12-20 13:50       ` Michal Hocko
2016-12-20 13:50         ` Michal Hocko
2016-12-20 17:38         ` Joe Perches [this message]
2016-12-20 17:38           ` Joe Perches
2016-12-20 22:13           ` Andrew Morton
2016-12-20 22:13             ` Andrew Morton
     [not found]             ` <20161221065922.GB16502@dhcp22.suse.cz>
2016-12-21  8:45               ` Michal Hocko
2016-12-21  8:45                 ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1482255502.1984.21.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=astepanov@cloudlinux.com \
    --cc=david@fromorbit.com \
    --cc=dm-devel@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rientjes@google.com \
    --cc=snitzer@redhat.com \
    --cc=tytso@mit.edu \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.