linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Ohhoon Kwon <ohkwon1043@gmail.com>
Cc: Christoph Lameter <cl@linux.com>,
	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>,
	JaeSang Yoo <jsyoo5b@gmail.com>,
	Wonhyuk Yang <vvghjk1234@gmail.com>,
	Jiyoup Kim <lakroforce@gmail.com>,
	Donghyeok Kim <dthex5d@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/slab_common: move dma-kmalloc caches creation into new_kmalloc_cache()
Date: Mon, 11 Apr 2022 20:07:55 +0900	[thread overview]
Message-ID: <YlQMC9x1hfgonJH/@hyeyoo> (raw)
In-Reply-To: <20220410162511.656541-1-ohkwon1043@gmail.com>

On Mon, Apr 11, 2022 at 01:25:11AM +0900, 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>
> ---
>  mm/slab_common.c | 18 +++---------------
>  1 file changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 6ee64d6208b3..a959d247c27b 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -849,6 +849,8 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type type, slab_flags_t flags)
>  			return;
>  		}
>  		flags |= SLAB_ACCOUNT;
> +	} else if (IS_ENABLED(CONFIG_ZONE_DMA) && (type == KMALLOC_DMA)) {
> +		flags |= SLAB_CACHE_DMA;
>  	}
>  
>  	kmalloc_caches[type][idx] = create_kmalloc_cache(
> @@ -877,7 +879,7 @@ void __init create_kmalloc_caches(slab_flags_t flags)
>  	/*
>  	 * Including KMALLOC_CGROUP if CONFIG_MEMCG_KMEM defined
>  	 */
> -	for (type = KMALLOC_NORMAL; type <= KMALLOC_RECLAIM; type++) {
> +	for (type = KMALLOC_NORMAL; type < NR_KMALLOC_TYPES; type++) {
>  		for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++) {
>  			if (!kmalloc_caches[type][i])
>  				new_kmalloc_cache(i, type, flags);
> @@ -898,20 +900,6 @@ void __init create_kmalloc_caches(slab_flags_t flags)
>  
>  	/* Kmalloc array is now usable */
>  	slab_state = UP;
> -
> -#ifdef CONFIG_ZONE_DMA
> -	for (i = 0; i <= KMALLOC_SHIFT_HIGH; i++) {
> -		struct kmem_cache *s = kmalloc_caches[KMALLOC_NORMAL][i];
> -
> -		if (s) {
> -			kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache(
> -				kmalloc_info[i].name[KMALLOC_DMA],
> -				kmalloc_info[i].size,
> -				SLAB_CACHE_DMA | flags, 0,
> -				kmalloc_info[i].size);
> -		}
> -	}
> -#endif
>  }
>  #endif /* !CONFIG_SLOB */
>

Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>

BTW this patch may conflict with [1] (not merged yet)

[1] https://lore.kernel.org/linux-mm/20220405135758.774016-9-catalin.marinas@arm.com/

Thanks!

> -- 
> 2.25.1
> 

-- 
Thanks,
Hyeonggon


       reply	other threads:[~2022-04-11 11:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220410162511.656541-1-ohkwon1043@gmail.com>
2022-04-11 11:07 ` Hyeonggon Yoo [this message]
2022-04-11 15:31   ` Vlastimil Babka
2022-04-12 16:55     ` Catalin Marinas
2022-04-12 23:38 ` David Rientjes

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=YlQMC9x1hfgonJH/@hyeyoo \
    --to=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=dthex5d@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jsyoo5b@gmail.com \
    --cc=lakroforce@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ohkwon1043@gmail.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    --cc=vvghjk1234@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox