From: Matthew Wilcox <willy@infradead.org>
To: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-doc@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 7/7] docs/core-api: mm-api: add section about GFP flags
Date: Thu, 26 Jul 2018 06:01:06 -0700 [thread overview]
Message-ID: <20180726130106.GC3504@bombadil.infradead.org> (raw)
In-Reply-To: <1532607722-17079-8-git-send-email-rppt@linux.vnet.ibm.com>
On Thu, Jul 26, 2018 at 03:22:02PM +0300, Mike Rapoport wrote:
> +Memory Allocation Controls
> +==========================
Perhaps call this section "Memory Allocation Flags" instead?
> +Linux provides a variety of APIs for memory allocation from direct
> +calls to page allocator through slab caches and vmalloc to allocators
> +of compressed memory. Although these allocators have different
> +semantics and are used in different circumstances, they all share the
> +GFP (get free page) flags that control behavior of each allocation
> +request.
While this isn't /wrong/, I think it might not be the most useful way
of explaining what the GFP flags are to someone who's just come across
them in some remote part of the kernel. How about this paragraph instead?
Functions which need to allocate memory often use GFP flags to express
how that memory should be allocated. The GFP acronym stands for "get
free pages", the underlying memory allocation function. Not every GFP
flag is allowed to every function which may allocate memory. Most
users will want to use a plain ``GFP_KERNEL`` or ``GFP_ATOMIC``.
> +.. kernel-doc:: include/linux/gfp.h
> + :doc: Page mobility and placement hints
> +
> +.. kernel-doc:: include/linux/gfp.h
> + :doc: Watermark modifiers
> +
> +.. kernel-doc:: include/linux/gfp.h
> + :doc: Reclaim modifiers
> +
> +.. kernel-doc:: include/linux/gfp.h
> + :doc: Common combinations
Would it make more sense to put 'common combinations' first?
next prev parent reply other threads:[~2018-07-26 13:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 12:21 [PATCH v2 0/7] memory management documentation updates Mike Rapoport
2018-07-26 12:21 ` [PATCH v2 1/7] mm/util: make strndup_user description a kernel-doc comment Mike Rapoport
2018-07-26 12:21 ` [PATCH v2 2/7] mm/util: add kernel-doc for kvfree Mike Rapoport
2018-07-26 12:21 ` [PATCH v2 3/7] docs/core-api: kill trailing whitespace in kernel-api.rst Mike Rapoport
2018-07-26 12:21 ` [PATCH v2 4/7] docs/core-api: move *{str,mem}dup* to "String Manipulation" Mike Rapoport
2018-07-26 12:22 ` [PATCH v2 5/7] docs/core-api: split memory management API to a separate file Mike Rapoport
2018-07-26 12:22 ` [PATCH v2 6/7] docs/mm: make GFP flags descriptions usable as kernel-doc Mike Rapoport
2018-07-26 12:22 ` [PATCH v2 7/7] docs/core-api: mm-api: add section about GFP flags Mike Rapoport
2018-07-26 13:01 ` Matthew Wilcox [this message]
2018-07-26 14:20 ` Michal Hocko
2018-07-26 15:18 ` Mike Rapoport
2018-07-26 15:36 ` Matthew Wilcox
2018-07-26 16:41 ` Michal Hocko
2018-07-26 17:24 ` Mike Rapoport
2018-07-26 15:29 ` Mike Rapoport
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=20180726130106.GC3504@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@linux.vnet.ibm.com \
/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).