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: Tue, 17 Jan 2017 08:51:01 +0100 [thread overview]
Message-ID: <20170117075100.GB19699@dhcp22.suse.cz> (raw)
In-Reply-To: <be93f879-6bc7-a09e-26f3-09c82c669d74@nvidia.com>
On Mon 16-01-17 13:57:43, John Hubbard wrote:
>
>
> On 01/16/2017 01:48 PM, Michal Hocko wrote:
> > On Mon 16-01-17 13:15:08, John Hubbard wrote:
> > >
> > >
> > > On 01/16/2017 11:40 AM, Michal Hocko wrote:
> > > > 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.
> > >
> > > OK, let's just fortify the documentation ever so slightly, then, so that
> > > users are more likely to do the right thing. How's this sound:
> > >
> > > * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
> > > * though the current implementation passes the flags on through to kmalloc and
> > > * vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
> > > * should not pass in these flags.)
> > > *
> > > * __GFP_REPEAT is supported, but only for large (>64kB) allocations.
> > >
> > >
> > > ? Or is that documentation overkill?
> >
> > Dunno, it sounds like an overkill to me. It is telling more than
> > necessary. If we want to be so vocal about gfp flags then we would have
> > to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is
> > supported for vmalloc while unsupported for kmalloc. I am pretty sure
> > there would be other gfp flags to consider and then this would grow
> > borringly large and uninteresting to the point when people simply stop
> > reading it. Let's just be as simple as possible.
>
> Agreed, on the simplicity point: simple and clear is ideal. But here, it's
> merely short, and not quite simple. :) People will look at that short bit
> of documentation, and then notice that the flags are, in fact, all passed
> right on through down to both kmalloc_node and __vmalloc_node_flags.
>
> If you don't want too much documentation, then I'd be inclined to say
> something higher-level, about the intent, rather than mentioning those two
> flags directly. Because as it stands, the documentation contradicts what the
> code does.
Feel free to suggest a better wording. I am, of course, open to any
changes.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2017-01-17 7:52 UTC|newest]
Thread overview: 55+ 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 ` [PATCH 1/6] mm: introduce kv[mz]alloc helpers Michal Hocko
2017-01-16 4:34 ` John Hubbard
2017-01-16 8:47 ` Michal Hocko
2017-01-16 19:09 ` John Hubbard
2017-01-16 19:40 ` Michal Hocko
2017-01-16 21:15 ` John Hubbard
2017-01-16 21:48 ` Michal Hocko
2017-01-16 21:57 ` John Hubbard
2017-01-17 7:51 ` Michal Hocko [this message]
2017-01-18 5:59 ` John Hubbard
2017-01-18 8:21 ` Michal Hocko
2017-01-19 8:37 ` John Hubbard
2017-01-19 8:45 ` Michal Hocko
2017-01-19 9:09 ` John Hubbard
2017-01-19 9:56 ` Michal Hocko
2017-01-19 21:28 ` John Hubbard
2017-01-26 12:09 ` Michal Hocko
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 16:12 ` Michael S. Tsirkin
2017-01-14 2:42 ` Tetsuo Handa
2017-01-14 8:45 ` Michal Hocko
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 ` [PATCH 4/6] ila: " 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:57 ` David Sterba
2017-01-12 16:05 ` Christian Borntraeger
2017-01-12 16:54 ` Ilya Dryomov
2017-01-12 17:18 ` Michal Hocko
2017-01-12 17:00 ` Dan Williams
2017-01-12 17:26 ` Kees Cook
2017-01-12 17:37 ` Michal Hocko
2017-01-20 13:41 ` Vlastimil Babka
2017-01-24 15:00 ` Michal Hocko
2017-01-25 11:15 ` Vlastimil Babka
2017-01-25 13:09 ` Michal Hocko
2017-01-25 13:40 ` Ilya Dryomov
2017-01-12 17:29 ` Michal Hocko
2017-01-14 3:01 ` Tetsuo Handa
2017-01-14 8:49 ` Michal Hocko
2017-01-12 20:14 ` Boris Ostrovsky
2017-01-13 1:11 ` Dilger, Andreas
2017-01-14 10:56 ` Leon Romanovsky
2017-01-16 7:33 ` Michal Hocko
2017-01-16 8:28 ` Leon Romanovsky
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-24 15:17 ` [PATCH 0/6 v3] kvmalloc Michal Hocko
2017-01-24 16:00 ` Eric Dumazet
2017-01-25 13:10 ` Michal Hocko
2017-01-24 19:17 ` Alexei Starovoitov
2017-01-25 13:10 ` 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=20170117075100.GB19699@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).