All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Anatoly Stepanov <astepanov@cloudlinux.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers
Date: Mon, 16 Jan 2017 20:40:53 +0100	[thread overview]
Message-ID: <20170116194052.GA9382@dhcp22.suse.cz> (raw)
In-Reply-To: <0ca8a212-c651-7915-af25-23925e1c1cc3@nvidia.com>

On Mon 16-01-17 11:09:37, John Hubbard wrote:
> 
> 
> On 01/16/2017 12:47 AM, Michal Hocko wrote:
> > On Sun 15-01-17 20:34:13, John Hubbard wrote:
[...]
> > > Is that "Reclaim modifiers" line still true, or is it a leftover from an
> > > earlier approach? I am having trouble reconciling it with rest of the
> > > patchset, because:
> > > 
> > > a) the flags argument below is effectively passed on to either kmalloc_node
> > > (possibly adding, but not removing flags), or to __vmalloc_node_flags.
> > 
> > The above only says thos are _unsupported_ - in other words the behavior
> > is not defined. Even if flags are passed down to kmalloc resp. vmalloc
> > it doesn't mean they are used that way.  Remember that vmalloc uses
> > some hardcoded GFP_KERNEL allocations.  So while I could be really
> > strict about this and mask away these flags I doubt this is worth the
> > additional code.
> 
> I do wonder about passing those flags through to kmalloc. Maybe it is worth
> stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some
> insulation from any future changes to the implementation of kmalloc, and it
> also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these
flags. There are no existing users for those flags and new users should
follow the documentation.

-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Anatoly Stepanov <astepanov@cloudlinux.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers
Date: Mon, 16 Jan 2017 20:40:53 +0100	[thread overview]
Message-ID: <20170116194052.GA9382@dhcp22.suse.cz> (raw)
In-Reply-To: <0ca8a212-c651-7915-af25-23925e1c1cc3@nvidia.com>

On Mon 16-01-17 11:09:37, John Hubbard wrote:
> 
> 
> On 01/16/2017 12:47 AM, Michal Hocko wrote:
> > On Sun 15-01-17 20:34:13, John Hubbard wrote:
[...]
> > > Is that "Reclaim modifiers" line still true, or is it a leftover from an
> > > earlier approach? I am having trouble reconciling it with rest of the
> > > patchset, because:
> > > 
> > > a) the flags argument below is effectively passed on to either kmalloc_node
> > > (possibly adding, but not removing flags), or to __vmalloc_node_flags.
> > 
> > The above only says thos are _unsupported_ - in other words the behavior
> > is not defined. Even if flags are passed down to kmalloc resp. vmalloc
> > it doesn't mean they are used that way.  Remember that vmalloc uses
> > some hardcoded GFP_KERNEL allocations.  So while I could be really
> > strict about this and mask away these flags I doubt this is worth the
> > additional code.
> 
> I do wonder about passing those flags through to kmalloc. Maybe it is worth
> stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some
> insulation from any future changes to the implementation of kmalloc, and it
> also makes the documentation more believable.

I am not really convinced that we should take an extra steps for these
flags. There are no existing users for those flags and new users should
follow the documentation.

-- 
Michal Hocko
SUSE Labs

--
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:[~2017-01-16 19:41 UTC|newest]

Thread overview: 129+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12 15:37 [PATCH 0/6 v3] kvmalloc Michal Hocko
2017-01-12 15:37 ` Michal Hocko
2017-01-12 15:37 ` [PATCH 1/6] mm: introduce kv[mz]alloc helpers Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-16  4:34   ` John Hubbard
2017-01-16  4:34     ` John Hubbard
2017-01-16  8:47     ` Michal Hocko
2017-01-16  8:47       ` Michal Hocko
2017-01-16 19:09       ` John Hubbard
2017-01-16 19:09         ` John Hubbard
2017-01-16 19:40         ` Michal Hocko [this message]
2017-01-16 19:40           ` Michal Hocko
2017-01-16 21:15           ` John Hubbard
2017-01-16 21:15             ` John Hubbard
2017-01-16 21:48             ` Michal Hocko
2017-01-16 21:48               ` Michal Hocko
2017-01-16 21:57               ` John Hubbard
2017-01-16 21:57                 ` John Hubbard
2017-01-17  7:51                 ` Michal Hocko
2017-01-17  7:51                   ` Michal Hocko
2017-01-18  5:59                   ` John Hubbard
2017-01-18  5:59                     ` John Hubbard
2017-01-18  8:21                     ` Michal Hocko
2017-01-18  8:21                       ` Michal Hocko
2017-01-19  8:37                       ` John Hubbard
2017-01-19  8:37                         ` John Hubbard
2017-01-19  8:45                         ` Michal Hocko
2017-01-19  8:45                           ` Michal Hocko
2017-01-19  9:09                           ` John Hubbard
2017-01-19  9:09                             ` John Hubbard
2017-01-19  9:56                             ` Michal Hocko
2017-01-19  9:56                               ` Michal Hocko
2017-01-19 21:28                               ` John Hubbard
2017-01-19 21:28                                 ` John Hubbard
2017-01-26 12:09   ` Michal Hocko
2017-01-26 12:09     ` Michal Hocko
2017-01-30  8:42     ` Vlastimil Babka
2017-01-30  8:42       ` Vlastimil Babka
2017-01-12 15:37 ` [PATCH 2/6] mm: support __GFP_REPEAT in kvmalloc_node for >=64kB Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-12 16:12   ` Michael S. Tsirkin
2017-01-12 16:12     ` Michael S. Tsirkin
2017-01-14  2:42   ` Tetsuo Handa
2017-01-14  2:42     ` Tetsuo Handa
2017-01-14  8:45     ` Michal Hocko
2017-01-14  8:45       ` Michal Hocko
2017-01-24 15:40   ` Michael S. Tsirkin
2017-01-24 15:40     ` Michael S. Tsirkin
2017-01-12 15:37 ` [PATCH 3/6] rhashtable: simplify a strange allocation pattern Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-12 15:37 ` [PATCH 4/6] ila: " Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-12 15:37 ` [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-12 15:57   ` David Sterba
2017-01-12 15:57     ` David Sterba
2017-01-12 15:57     ` David Sterba
2017-01-12 16:05   ` Christian Borntraeger
2017-01-12 16:05     ` Christian Borntraeger
2017-01-12 16:05     ` Christian Borntraeger
2017-01-12 16:54   ` Ilya Dryomov
2017-01-12 16:54     ` Ilya Dryomov
2017-01-12 16:54     ` Ilya Dryomov
2017-01-12 17:18     ` Michal Hocko
2017-01-12 17:18       ` Michal Hocko
2017-01-12 17:18       ` Michal Hocko
2017-01-12 17:00   ` Dan Williams
2017-01-12 17:00     ` Dan Williams
2017-01-12 17:00     ` Dan Williams
2017-01-12 17:26   ` Kees Cook
2017-01-12 17:26     ` Kees Cook
2017-01-12 17:26     ` Kees Cook
2017-01-12 17:37     ` Michal Hocko
2017-01-12 17:37       ` Michal Hocko
2017-01-12 17:37       ` Michal Hocko
2017-01-20 13:41       ` Vlastimil Babka
2017-01-20 13:41         ` Vlastimil Babka
2017-01-20 13:41         ` Vlastimil Babka
2017-01-24 15:00         ` Michal Hocko
2017-01-24 15:00           ` Michal Hocko
2017-01-24 15:00           ` Michal Hocko
2017-01-25 11:15           ` Vlastimil Babka
2017-01-25 11:15             ` Vlastimil Babka
2017-01-25 11:15             ` Vlastimil Babka
2017-01-25 13:09             ` Michal Hocko
2017-01-25 13:09               ` Michal Hocko
2017-01-25 13:09               ` Michal Hocko
2017-01-25 13:40               ` Ilya Dryomov
2017-01-25 13:40                 ` Ilya Dryomov
2017-01-25 13:40                 ` Ilya Dryomov
2017-01-12 17:29   ` Michal Hocko
2017-01-12 17:29     ` Michal Hocko
2017-01-12 17:29     ` Michal Hocko
2017-01-14  3:01     ` Tetsuo Handa
2017-01-14  3:01       ` Tetsuo Handa
2017-01-14  8:49       ` Michal Hocko
2017-01-14  8:49         ` Michal Hocko
2017-01-12 20:14   ` Boris Ostrovsky
2017-01-12 20:14     ` Boris Ostrovsky
2017-01-12 20:14     ` Boris Ostrovsky
2017-01-13  1:11   ` Dilger, Andreas
2017-01-13  1:11     ` Dilger, Andreas
2017-01-13  1:11     ` Dilger, Andreas
2017-01-14 10:56   ` Leon Romanovsky
2017-01-14 10:56     ` Leon Romanovsky
2017-01-16  7:33     ` Michal Hocko
2017-01-16  7:33       ` Michal Hocko
2017-01-16  7:33       ` Michal Hocko
2017-01-16  8:28       ` Leon Romanovsky
2017-01-16  8:28         ` Leon Romanovsky
2017-01-16  8:18   ` Tariq Toukan
2017-01-16  8:18     ` Tariq Toukan
2017-01-16  8:18     ` Tariq Toukan
2017-01-12 15:37 ` [RFC PATCH 6/6] net: use kvmalloc with __GFP_REPEAT rather than open coded variant Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-24 15:17 ` [PATCH 0/6 v3] kvmalloc Michal Hocko
2017-01-24 15:17   ` Michal Hocko
2017-01-24 16:00   ` Eric Dumazet
2017-01-24 16:00     ` Eric Dumazet
2017-01-25 13:10     ` Michal Hocko
2017-01-25 13:10       ` Michal Hocko
2017-01-24 19:17   ` Alexei Starovoitov
2017-01-24 19:17     ` Alexei Starovoitov
2017-01-25 13:10     ` Michal Hocko
2017-01-25 13:10       ` Michal Hocko
2017-01-25 13:21       ` Michal Hocko
2017-01-25 13:21         ` 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=20170116194052.GA9382@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=astepanov@cloudlinux.com \
    --cc=hannes@cmpxchg.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --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.