From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3265C46D543; Mon, 31 Aug 2026 17:20:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788196825; cv=none; b=GAAodG2l0xATKAZlW5awTXoQh4AzNrKqdImsMl6AgVGzuDjTNjQ4Q59ijGjO5MmihtyljagFytQ9DXtkFVnF8+YSfbGmqVlGbQiqk1gWmYW8BROurCCdBFSZjafVVNJ4yaxNLSLBfu6sSdeUzoBNnejciJzQO4no3M+L+PT4CZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788196825; c=relaxed/simple; bh=aQsq4xX0eIMwQDuQi/uZ+KgXBfXlENgo0fT1UN7GoSs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=guxs+uoOPyEZxmuE7lUw0Y4GY0JSTrn4ZQ3AiBNTqzzNIaWePY8fIY73q310dRU3/smGOiMkLA1GXTE7p+qUmVzGTtfORc8N0YsgBN3mSMd8hxnkBXbJfzbJkjdvqotKwcYvwahLfn62rCzQS+UzALs9SUsMau9ZZWrNH4jst94= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=e3qOWSeQ; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="e3qOWSeQ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=pQUHwKk0U77GfMYQ/2B5fWOyPHpUKlicsOQQN5flvaI=; b=e3qOWSeQPOB4I33XJBkgSPh4V0 Hdtl6j8ja41PVzOkvoVC2RB8LJvnFAkXaSAHdcDAGNj3ca3Uu5aec1OSyU5U9QqvHh9nzHGCdQqHc MeejhveBfSkwi+6C90XWAyNrfklIhaWlIer5V+uE/Ng2l0pMK6o6cEwnCCwHsF2wJL2vfOiSPu3NB 4VHGV0yAlGQvPYZMPDhajMcKwv6fWZyheCYt+98hKkOcmqcuTAS4uWE8jIlKPk53DRUW2dzq4w6Rl Wtrkh7W6jrd1dTPX99tuYszUAh7lTqlB3mBEuOfnIdLE6N1dhrC7QlOmWbbfgoapJ95GzcCNGzEL8 PjAYmU0A==; Received: from [50.53.43.113] (helo=[192.168.254.34]) by bombadil.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1x15gD-0000000A9zs-2le5; Mon, 31 Aug 2026 17:20:21 +0000 Message-ID: Date: Mon, 31 Aug 2026 10:20:20 -0700 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] docs/core-api: memory-allocation: add k[mz]alloc_obj() and clarify kmalloc To: "Mike Rapoport (Microsoft)" , Jonathan Corbet , Andrew Morton , David Hildenbrand Cc: "Liam R. Howlett" , Lorenzo Stoakes , Michal Hocko , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20260831-docs-memalloc-guide-v1-0-547718c274c1@kernel.org> <20260831-docs-memalloc-guide-v1-1-547718c274c1@kernel.org> Content-Language: en-US From: Randy Dunlap In-Reply-To: <20260831-docs-memalloc-guide-v1-1-547718c274c1@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/31/26 8:13 AM, Mike Rapoport (Microsoft) 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 > and make kzalloc_obj() the first answer to "How should I allocate > memory?" question. > > While on it, clarify description of kmalloc() size limitations. > > Signed-off-by: Mike Rapoport (Microsoft) > --- > 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(); > + > +or > + > :: > > kzalloc(, 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(). > > 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 `MAX_ORDER`; the > +same limit also applies to the page allocator. > + > +Internally, slab allocator differentiates allocations of different orders and the slab allocator ? > +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 > -- ~Randy