From: Mike Rapoport <rppt@linux.ibm.com>
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: corbet@lwn.net, willy@infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] docs/core-api: memory-allocation: remove uses of c:func:
Date: Fri, 25 Oct 2019 23:26:35 +0300 [thread overview]
Message-ID: <20191025202634.GD8710@linux.ibm.com> (raw)
In-Reply-To: <20191024195016.11054-3-chris.packham@alliedtelesis.co.nz>
On Fri, Oct 25, 2019 at 08:50:15AM +1300, Chris Packham wrote:
> These are no longer needed as the documentation build will automatically
> add the cross references.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>
> Notes:
> It should be noted that kvmalloc() and kmem_cache_destroy() lack a
> kerneldoc header, a side-effect of this change is that the :c:func:
> fallback of making them bold is lost. This is probably best fixed by
> adding a kerneldoc header to their source.
You are more than welcome to add them ;-)
> Changes in v2:
> - new
>
> Documentation/core-api/memory-allocation.rst | 49 +++++++++-----------
> 1 file changed, 23 insertions(+), 26 deletions(-)
>
> diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst
> index dcf851b4520f..e47d48655085 100644
> --- a/Documentation/core-api/memory-allocation.rst
> +++ b/Documentation/core-api/memory-allocation.rst
> @@ -88,10 +88,10 @@ Selecting memory allocator
> ==========================
>
> The most straightforward way to allocate memory is to use a function
> -from the :c:func:`kmalloc` family. And, to be on the safe side it's
> -best to use routines that set memory to zero, like
> -:c:func:`kzalloc`. If you need to allocate memory for an array, there
> -are :c:func:`kmalloc_array` and :c:func:`kcalloc` helpers.
> +from the kmalloc() family. And, to be on the safe side it's best to use
> +routines that set memory to zero, like kzalloc(). If you need to
> +allocate memory for an array, there are kmalloc_array() and kcalloc()
> +helpers.
>
> The maximal size of a chunk that can be allocated with `kmalloc` is
> limited. The actual limit depends on the hardware and the kernel
> @@ -102,29 +102,26 @@ The address of a chunk allocated with `kmalloc` is aligned to at least
> ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
> alignment is also guaranteed to be at least the respective size.
>
> -For large allocations you can use :c:func:`vmalloc` and
> -:c:func:`vzalloc`, or directly request pages from the page
> -allocator. The memory allocated by `vmalloc` and related functions is
> -not physically contiguous.
> +For large allocations you can use vmalloc() and vzalloc(), or directly
> +request pages from the page allocator. The memory allocated by `vmalloc`
> +and related functions is not physically contiguous.
>
> If you are not sure whether the allocation size is too large for
> -`kmalloc`, it is possible to use :c:func:`kvmalloc` and its
> -derivatives. It will try to allocate memory with `kmalloc` and if the
> -allocation fails it will be retried with `vmalloc`. There are
> -restrictions on which GFP flags can be used with `kvmalloc`; please
> -see :c:func:`kvmalloc_node` reference documentation. Note that
> -`kvmalloc` may return memory that is not physically contiguous.
> +`kmalloc`, it is possible to use kvmalloc() and its derivatives. It will
> +try to allocate memory with `kmalloc` and if the allocation fails it
> +will be retried with `vmalloc`. There are restrictions on which GFP
> +flags can be used with `kvmalloc`; please see kvmalloc_node() reference
> +documentation. Note that `kvmalloc` may return memory that is not
> +physically contiguous.
>
> If you need to allocate many identical objects you can use the slab
> -cache allocator. The cache should be set up with
> -:c:func:`kmem_cache_create` or :c:func:`kmem_cache_create_usercopy`
> -before it can be used. The second function should be used if a part of
> -the cache might be copied to the userspace. After the cache is
> -created :c:func:`kmem_cache_alloc` and its convenience wrappers can
> -allocate memory from that cache.
> -
> -When the allocated memory is no longer needed it must be freed. You
> -can use :c:func:`kvfree` for the memory allocated with `kmalloc`,
> -`vmalloc` and `kvmalloc`. The slab caches should be freed with
> -:c:func:`kmem_cache_free`. And don't forget to destroy the cache with
> -:c:func:`kmem_cache_destroy`.
> +cache allocator. The cache should be set up with kmem_cache_create() or
> +kmem_cache_create_usercopy() before it can be used. The second function
> +should be used if a part of the cache might be copied to the userspace.
> +After the cache is created kmem_cache_alloc() and its convenience
> +wrappers can allocate memory from that cache.
> +
> +When the allocated memory is no longer needed it must be freed. You can
> +use kvfree() for the memory allocated with `kmalloc`, `vmalloc` and
> +`kvmalloc`. The slab caches should be freed with kmem_cache_free(). And
> +don't forget to destroy the cache with kmem_cache_destroy().
> --
> 2.23.0
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2019-10-25 20:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 19:50 [PATCH v3 0/3] docs/core-api: memory-allocation: minor cleanups Chris Packham
2019-10-24 19:50 ` [PATCH v3 1/3] docs/core-api: memory-allocation: fix typo Chris Packham
2019-10-24 19:50 ` [PATCH v3 2/3] docs/core-api: memory-allocation: remove uses of c:func: Chris Packham
2019-10-24 20:29 ` Jonathan Corbet
2019-10-24 20:51 ` Chris Packham
2019-10-24 20:57 ` Jonathan Corbet
2019-10-24 21:07 ` Chris Packham
2019-10-25 20:26 ` Mike Rapoport [this message]
2019-10-24 19:50 ` [PATCH v3 3/3] docs/core-api: memory-allocation: mention size helpers Chris Packham
2019-10-24 20:16 ` [PATCH v3 0/3] docs/core-api: memory-allocation: minor cleanups Matthew Wilcox
2019-10-25 20:25 ` Mike Rapoport
2019-10-29 10:46 ` Jonathan Corbet
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=20191025202634.GD8710@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.org \
/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.