From: "Christoph Lameter (Ampere)" <cl@linux.com>
To: Hyunmin Lee <hyunminlr@gmail.com>
Cc: linux-mm@kvack.org, Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Jeungwoo Yoo <casionwoo@gmail.com>,
Sangyun Kim <sangyun.kim@snu.ac.kr>,
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Subject: Re: [PATCH v3 1/2] mm/slub: create kmalloc 96 and 192 caches regardless cache size order
Date: Wed, 24 Apr 2024 10:04:38 -0700 (PDT) [thread overview]
Message-ID: <8e4cebb2-c244-de0b-1df6-91a8276cdf3b@linux.com> (raw)
In-Reply-To: <20240424140422.12780-2-hyunminlr@gmail.com>
On Wed, 24 Apr 2024, Hyunmin Lee wrote:
> For SLAB the kmalloc caches needed to be created in ascending sizes in
> order. However, the constraint is not necessary anymore because SLAB has
> been removed and SLUB doesn't need to comply with the constraint. Thus,
> kmalloc 96 and 192 caches can be created after the other size kmalloc
> caches are created instead of checking every time to find their order to
> be created. Also, this change could prevent engineers from being confused
> by the removed constraint.
Reviewed-by: Christoph Lameter <cl@linux.com>
next prev parent reply other threads:[~2024-04-24 17:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 14:04 [PATCH v3 0/2] clean-up for create_kmalloc_caches() Hyunmin Lee
2024-04-24 14:04 ` [PATCH v3 1/2] mm/slub: create kmalloc 96 and 192 caches regardless cache size order Hyunmin Lee
2024-04-24 17:04 ` Christoph Lameter (Ampere) [this message]
2024-04-27 4:51 ` David Rientjes
2024-04-24 14:04 ` [PATCH v3 2/2] mm/slub: remove the check for NULL kmalloc_caches Hyunmin Lee
2024-04-24 17:05 ` Christoph Lameter (Ampere)
2024-04-27 4:51 ` David Rientjes
2024-05-02 14:12 ` [PATCH v3 0/2] clean-up for create_kmalloc_caches() Vlastimil Babka
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=8e4cebb2-c244-de0b-1df6-91a8276cdf3b@linux.com \
--to=cl@linux.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=casionwoo@gmail.com \
--cc=gwan-gyeong.mun@intel.com \
--cc=hyunminlr@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=sangyun.kim@snu.ac.kr \
--cc=vbabka@suse.cz \
/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.