Received: by 2002:a05:6a10:87d6:0:0:0:0 with SMTP id g22csp1051136pxr; Mon, 11 Apr 2022 13:54:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhI85DvS86hR9iZtROuTJnnFiw8QtzmAkYeZgB8Zud7k7gAwMqLiyRA4jLF4xvynStskxK X-Received: by 2002:a63:cc53:0:b0:372:7d69:49fb with SMTP id q19-20020a63cc53000000b003727d6949fbmr28310441pgi.21.1649710484234; Mon, 11 Apr 2022 13:54:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649710484; cv=none; d=google.com; s=arc-20160816; b=sfRzfE3LB+YVnt6aX6gK7+e2G3GxJ/rwYMO1OPnB39LrQwfVdKf4qjKge8JwfAuvRj tlzo7g6Vk2eoNZ7gNcRIVMUPSBOHwNOz6Bd/UghySgW8z5czQPcWDpHQU0GouOJwInBL 1wJMYF6WRjk5EZnHU5o8qmV21JJGMVgLgR1MR+evQOJRbDMA97KSfvvVUp7lFg8VQNMk +A7t9wURHBfi1q8NR1ABqkRw2w6L61iNB5UmYKUsSifUirw+mPwyAsRwnOcLMEMgNYUC exwBXknAmuKMdZ1l89JGgLq7XbDzFmuUuALdq8ix1/PEdDsh0Z1ORRHY7jdKg/ZkHlyF tsdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=kiJ9APoqAB53N14utwlexldPR1v9F4okKCVpXr8jG00=; b=trBV4tKdNAiS1T/hU3nvW1/qWFGGCsinLFU8ld9XkShbH6uZf9UQtbLRDRQ14Qu5Cb n19spJxGbi/rLv93Z/lgGYIGNSCu1Riu1giZ0b7+y7aWf1toVNu4wdqRII6iCpO+4Bt7 q8pCcHRgKZ3z6dCuVIgKSvao2ERR0NSqDN9gQeUXyMvj0IEGbNU3BBZ6gMZzOSWBnQ8d 582OlYQgj5bH/oDVikVIyXhgU1mdrYg4VhGK05r7RgIEkNad3II/Ig6nngg1jZx2j1ft ECIp+dkSC4AQv/J5z8c/y/Mci3na5/5rh9SF8FoYLMXAqs0LOYvKP1Z/mDMUbYaFPzfX TzBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=n4zvGtKX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w191-20020a6382c8000000b003816043ee33si835724pgd.40.2022.04.11.13.54.29; Mon, 11 Apr 2022 13:54:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=n4zvGtKX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233370AbiDJGyW (ORCPT + 99 others); Sun, 10 Apr 2022 02:54:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbiDJGyU (ORCPT ); Sun, 10 Apr 2022 02:54:20 -0400 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 343E65F27E for ; Sat, 9 Apr 2022 23:52:08 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id f3so11985560pfe.2 for ; Sat, 09 Apr 2022 23:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kiJ9APoqAB53N14utwlexldPR1v9F4okKCVpXr8jG00=; b=n4zvGtKXRzvGFfyO3u/RNn7kM4d6vqAkqEHKtvH94+JyXQY08F95Ae572CgcNvQt39 QtsCxAue8NbjMVDm4IeiAEIETT1QRZIHzAvpmkpNOQA55khboNhaNJ+N8v53Xw/URXg6 mz+jpvR2TVvxY8CWG2y7mt62Vz/CLURZL82BpHENZPLBNfBpTMEVC3PXCTPcYHJ8IlMT Vc2QhIyD4eo/pJZy6tGw31URtk68oNwH0himZ9JTkKtfXwAGGucL+aSSMtETLuaVrJPR 2PN14tnO9ha1xj5JAExdib4hzuWpTxOQcQ19nIvb1bT3ni95TfExlidI0/9QwBcf1fIv 8nOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kiJ9APoqAB53N14utwlexldPR1v9F4okKCVpXr8jG00=; b=1DjOSW26wN3ExtqoymZY90v4XCV2VvOR5CpU7B15rD3GnfhI8mVacwz6w67+9AVy8z QgmGUPQR8pgHX/hHBCliffuT3Lw0eXL6XEKRAXRJVa0Dn46skhxQXb/QLZ5u0HYRCdmO fPMaFpWVnBtVGEX/0PVxOfFcZ6kZGp2CPJCclehIVo7R9TZcH0Dvn9eRkEdrYHYRJv3L S7wwAyxXw/cYiIDI4hj28L4zEAkICDzXWGM4sgSR6KiNIN8EqF61b8fB4t1QsrD1dpkE ZfGUE1xM8QwLhvIoKj+58ZGE2xUORwmj4DyHtdssUS9Pm2UgBWYpaPeL+y/PXPWB1vWy ZkUQ== X-Gm-Message-State: AOAM532b+w75PpLNB239/Q1GVaqTQoSHmP9mS0xjBfEXiKJYd62H0Guz fxgaLPjNGoGbyiaHK+wOfmk= X-Received: by 2002:a63:ed45:0:b0:399:5116:312a with SMTP id m5-20020a63ed45000000b003995116312amr21326806pgk.611.1649573527624; Sat, 09 Apr 2022 23:52:07 -0700 (PDT) Received: from hyeyoo ([114.29.24.243]) by smtp.gmail.com with ESMTPSA id y3-20020a056a00190300b004fa2411bb92sm32594637pfi.93.2022.04.09.23.52.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Apr 2022 23:52:06 -0700 (PDT) Date: Sun, 10 Apr 2022 15:51:57 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Ohhoon Kwon Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jiyoup Kim , Wonhyuk Yang , Donghyeok Kim , JaeSang Yoo Subject: Re: [PATCH] mm/slab_common: move dma-kmalloc caches creation into new_kmalloc_cache() Message-ID: References: <20220409095305.586412-1-ohkwon1043@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220409095305.586412-1-ohkwon1043@gmail.com> X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HK_RANDOM_ENVFROM, HK_RANDOM_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 09, 2022 at 06:53:05PM +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- > 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- 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 > Signed-off-by: JaeSang Yoo > Signed-off-by: Ohhoon Kwon > --- > mm/slab_common.c | 20 +++++--------------- > 1 file changed, 5 insertions(+), 15 deletions(-) > > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 6ee64d6208b3..eb95512de983 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -849,6 +849,10 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type type, slab_flags_t flags) > return; > } > flags |= SLAB_ACCOUNT; > +#ifdef CONFIG_ZONE_DMA > + } else if (type == KMALLOC_DMA) { > + flags |= SLAB_CACHE_DMA; > +#endif Maybe IS_ENABLED() would be better instead of ifdef for consistency? > } > > kmalloc_caches[type][idx] = create_kmalloc_cache( > @@ -877,7 +881,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 +902,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 */ The patch overall looks good to me. Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Thanks! > -- > 2.25.1 > > -- Thanks, Hyeonggon