From: SJ Park <sj@kernel.org>
To: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: SJ Park <sj@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
Randy Dunlap <rdunlap@infradead.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 1/2] docs/core-api: memory-allocation: add k[mz]alloc_obj() and clarify kmalloc
Date: Mon, 31 Aug 2026 20:39:38 -0700 [thread overview]
Message-ID: <20260901033938.91859-1-sj@kernel.org> (raw)
In-Reply-To: <20260831-docs-memalloc-guide-v1-1-547718c274c1@kernel.org>
On Mon, 31 Aug 2026 18:13:01 +0300 "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> Since v7.0 the most used memory allocation function is kzalloc_obj().
>
> Update hte memory-allocation guide to describe k[mz]alloc_obj() family
s/hte/the/
> and make kzalloc_obj() the first answer to "How should I allocate
> memory?" question.
>
> While on it, clarify description of kmalloc() size limitations.
Looks good improvements to me.
>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: SJ Park <sj@kernel.org>
> ---
> Documentation/core-api/memory-allocation.rst | 30 +++++++++++++++++++++-------
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst
> index 0f19dd5243239..8ecfa4d35f4f5 100644
> --- a/Documentation/core-api/memory-allocation.rst
> +++ b/Documentation/core-api/memory-allocation.rst
> @@ -19,6 +19,12 @@ Diversity of the allocation APIs combined with the numerous GFP flags
> makes the question "How should I allocate memory?" not that easy to
> answer, although very likely you should use
>
> +::
> +
> + kzalloc_obj(<VAR_OR_TYPE>);
> +
> +or
> +
> ::
>
> kzalloc(<size>, GFP_KERNEL);
> @@ -139,10 +145,13 @@ allocate memory for an array, there are kmalloc_array() and kcalloc()
> helpers. The helpers struct_size(), array_size() and array3_size() can
> be used to safely calculate object sizes without overflowing.
>
> -The maximal size of a chunk that can be allocated with `kmalloc` is
> -limited. The actual limit depends on the hardware and the kernel
> -configuration, but it is a good practice to use `kmalloc` for objects
> -smaller than page size.
> +Since 7.0 there are type aware kmalloc-family helpers that let you safely and
> +conveniently allocate a single object or arrays of objects with kzalloc_obj()
> +and kmalloc_obj() and their array versions kzalloc_objs() and
> +kmalloc_objs(). These helpers only need the type of the object that should be
> +allocated and the count of elements in the array for the array versions.
> +
> +As of v7.2, vast majority of the memory allocations use kzalloc_obj().
As the commit message says "Since v7.0 the most used memory allocation function
is kzalloc_obj()", should we s/7.2/7.0/ ?
I also feel like the above sentence might not really needed, or can be
version-neutral, e.g., Since its introduction, vast majoritiy of ... switched
to use ... ? No strong opinion.
>
> 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
> @@ -154,9 +163,16 @@ Chunks allocated with kmalloc() can be resized with krealloc(). Similarly
> to kmalloc_array(): a helper for resizing arrays is provided in the form of
> krealloc_array().
>
> -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.
> +`kmalloc` always allocates physically contiguous memory and the maximal size of
> +a chunk that can be allocated with `kmalloc` is limited by `MAX_ORDER`, the
> +same limit also applies to the page allocator.
I initially thought if it makes look more consistent by using kmalloc() instead
of `kmalloc`. But seems anyway we are mixing those here and there. So I have
no opinion.
> +
> +Internally, slab allocator differentiates allocations of different orders and
> +delegates larger allocations to the page allocator, but for the users of
> +`kmalloc` family it is entirely transparent.
> +
> +For large allocations that do not require physically contiguous memory you can
> +use vmalloc() and vzalloc() family.
>
> If you are not sure whether the allocation size is too large for
> `kmalloc`, it is possible to use kvmalloc() and its derivatives. It will
>
> --
> 2.53.0
Thanks,
SJ
next prev parent reply other threads:[~2026-09-01 3:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 15:13 [PATCH 0/2] docs/core-api: memory-allocation: add k[mz]alloc_obj() and clarify kmalloc Mike Rapoport (Microsoft)
2026-08-31 15:13 ` [PATCH 1/2] " Mike Rapoport (Microsoft)
2026-08-31 15:26 ` Suren Baghdasaryan
2026-08-31 17:20 ` Randy Dunlap
2026-09-01 3:39 ` SJ Park [this message]
2026-09-01 10:17 ` Vlastimil Babka (SUSE)
2026-09-01 16:10 ` Mike Rapoport
2026-09-02 7:50 ` Vlastimil Babka (SUSE)
2026-08-31 15:13 ` [PATCH 2/2] MAINTAINERS: add memory related docs in core-mm/ to MM - MISC section Mike Rapoport (Microsoft)
2026-08-31 15:17 ` Lorenzo Stoakes (ARM)
2026-09-01 3:42 ` SJ Park
2026-09-01 10:18 ` Vlastimil Babka (SUSE)
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=20260901033938.91859-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.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.