Messages in this thread | | | Date | Tue, 12 Apr 2022 16:38:21 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [PATCH v2] mm/slab_common: move dma-kmalloc caches creation into new_kmalloc_cache() |
| |
On Mon, 11 Apr 2022, Ohhoon Kwon wrote:
> There are four types of kmalloc_caches: KMALLOC_NORMAL, KMALLOC_CGROUP, > KMALLOC_RECLAIM, and KMALLOC_DMA. While the first three types are > created using new_kmalloc_cache(), KMALLOC_DMA caches are created in a > separate logic. Let KMALLOC_DMA caches be also created using > new_kmalloc_cache(), to enhance readability. > > Historically, there were only KMALLOC_NORMAL caches and KMALLOC_DMA > caches in the first place, and they were initialized in two separate > logics. However, when KMALLOC_RECLAIM was introduced in v4.20 via > commit 1291523f2c1d ("mm, slab/slub: introduce kmalloc-reclaimable > caches") and KMALLOC_CGROUP was introduced in v5.14 via > commit 494c1dfe855e ("mm: memcg/slab: create a new set of kmalloc-cg-<n> > caches"), their creations were merged with KMALLOC_NORMAL's only. > KMALLOC_DMA creation logic should be merged with them, too. > > By merging KMALLOC_DMA initialization with other types, the following > two changes might occur: > 1. The order dma-kmalloc-<n> caches added in slab_cache list may be > sorted by size. i.e. the order they appear in /proc/slabinfo may change > as well. > 2. slab_state will be set to UP after KMALLOC_DMA is created. > In case of slub, freelist randomization is dependent on slab_state>=UP, > and therefore KMALLOC_DMA cache's freelist will not be randomized in > creation, but will be deferred to init_freelist_randomization(). > > Co-developed-by: JaeSang Yoo <jsyoo5b@gmail.com> > Signed-off-by: JaeSang Yoo <jsyoo5b@gmail.com> > Signed-off-by: Ohhoon Kwon <ohkwon1043@gmail.com>
Acked-by: David Rientjes <rientjes@google.com>
| |