Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp7248995rwl; Thu, 23 Mar 2023 01:17:10 -0700 (PDT) X-Google-Smtp-Source: AK7set9E3qvcRviLBiYPU3SJgirrkxx48OQ21YgoL7zr3x895AtqpJ9DBCq1yCBncXNXxEYkeznO X-Received: by 2002:a05:6402:502:b0:4fb:999:e052 with SMTP id m2-20020a056402050200b004fb0999e052mr8495155edv.33.1679559430040; Thu, 23 Mar 2023 01:17:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679559430; cv=none; d=google.com; s=arc-20160816; b=qXSEx6JeT2CUrmmBWCmxzP/+UOacdX1z6H/O3N+8UvClzVDPWbGqy8RRYKZ57Hq1Z1 TotD/mF9b+qZamBKUHNGUSmv1W1F79F76+u2KcnnCZ/fkj4/RrYzdN39Wo+8YX9mULP3 zm41tdnWRtBbDfdR+qTCQ/MSEEw9QGywavKZhbuttP28YUNCJSdH681Nb5HgulhkMlfz YXFtAOdOTVu4V213drj2B6HDEH2XPbsnhQ2pENxf+xjELeL0R2f9DjWxiWkdTsEJFS1K 9RfOPN9jLY6ByVuUpfCuKSVnxZzhoHaApicJcw53m4sUG6vRIzuX5tVZRAYsHdeDHcN6 xCRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=mevmzcRW5raKRxRMUQm8jlYDge96hF8uqwcMTBFv9NY=; b=x+oVimjgnrwrZuc2sBohQicVWB2CzOn/r5Ncx18RLOLpQEVVvMU9SbvzAqueRwTLYA VpwtPTS7ROqsNWUchLUCi5c5nf76fLshABwBnFuP3EVJdTmNVvvE+ZaAKQK7r8kkVOYj Zdbm7U6eDXU4ANOztwhe5jDgq6NP3SGwv0SaEQM9B8wurmjrejwgPcrLSH5QiyAJCdAc GaIUAHQ4GrhGDRdj3Iyji5hC9z6nuac0KBV0tW5o7Yzzf0A0hDIzvt0fEFDL8x9TPhfm MgBpyXlB0rDohp+3Vnhb2f8r01BgzzZnA7uU7coszCb4PrGQ9B4vZM5V5UX2/+Lk4mSW Q4eA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i5-20020a056402054500b004fc9c1d4360si18299593edx.529.2023.03.23.01.16.44; Thu, 23 Mar 2023 01:17:10 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231152AbjCWIEv (ORCPT + 99 others); Thu, 23 Mar 2023 04:04:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231150AbjCWIEt (ORCPT ); Thu, 23 Mar 2023 04:04:49 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3745FF974 for ; Thu, 23 Mar 2023 01:04:48 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id C6BB968B05; Thu, 23 Mar 2023 09:04:43 +0100 (CET) Date: Thu, 23 Mar 2023 09:04:43 +0100 From: Christoph Hellwig To: Liu Shixin Cc: Seth Jennings , Dan Streetman , Vitaly Wool , Andrew Morton , Nathan Chancellor , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH -next v6 2/2] mm/zswap: delay the initializaton of zswap Message-ID: <20230323080443.GC20444@lst.de> References: <20230322102006.780624-1-liushixin2@huawei.com> <20230322102006.780624-3-liushixin2@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230322102006.780624-3-liushixin2@huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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 Wed, Mar 22, 2023 at 06:20:06PM +0800, Liu Shixin wrote: > Since some users may not use zswap, the zswap_pool is wasted. Save memory > by delaying the initialization of zswap until enabled. > > Signed-off-by: Liu Shixin > --- > mm/zswap.c | 51 +++++++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 41 insertions(+), 10 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 09fa956920fa..3aed3b26524a 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -81,6 +81,8 @@ static bool zswap_pool_reached_full; > > #define ZSWAP_PARAM_UNSET "" > > +static int zswap_setup(void); > + > /* Enable/disable zswap */ > static bool zswap_enabled = IS_ENABLED(CONFIG_ZSWAP_DEFAULT_ON); > static int zswap_enabled_param_set(const char *, > @@ -220,6 +222,9 @@ static bool zswap_init_started; > /* fatal error during init */ > static bool zswap_init_failed; > > +/* used to ensure the integrity of initialization */ > +static DEFINE_MUTEX(zswap_init_lock); > + > /* init completed, but couldn't create the initial pool */ > static bool zswap_has_pool; > > @@ -272,13 +277,13 @@ static void zswap_update_total_size(void) > **********************************/ > static struct kmem_cache *zswap_entry_cache; > > -static int __init zswap_entry_cache_create(void) > +static int zswap_entry_cache_create(void) > { > zswap_entry_cache = KMEM_CACHE(zswap_entry, 0); > return zswap_entry_cache == NULL; > } Please add a cleanup patch to remove this helper first, it just massivel confuses the reader. > -static void __init zswap_entry_cache_destroy(void) > +static void zswap_entry_cache_destroy(void) > { > kmem_cache_destroy(zswap_entry_cache); > } Same here. > @@ -663,7 +668,7 @@ static struct zswap_pool *zswap_pool_create(char *type, char *compressor) > return NULL; > } > > -static __init struct zswap_pool *__zswap_pool_create_fallback(void) > +static struct zswap_pool *__zswap_pool_create_fallback(void) > { > bool has_comp, has_zpool; > > @@ -784,8 +789,15 @@ static int __zswap_param_set(const char *val, const struct kernel_param *kp, > /* if this is load-time (pre-init) param setting, > * don't create a pool; that's done during init. > */ > - if (!zswap_init_started) > - return param_set_charp(s, kp); > + if (!zswap_init_started) { > + mutex_lock(&zswap_init_lock); > + if (!zswap_init_started) { > + ret = param_set_charp(s, kp); > + mutex_unlock(&zswap_init_lock); > + return ret; > + } > + mutex_unlock(&zswap_init_lock); > + } Just take the lock around the whole function. No need to micro-optimize setting a kernel paramter. > @@ -884,6 +896,15 @@ static int zswap_enabled_param_set(const char *val, > if (res == *(bool *)kp->arg) > return 0; > > + if (!zswap_init_started && (system_state == SYSTEM_RUNNING)) { No need for the inner braces. But directly looking at SYSTEM_RUNNING, especially without a comment is a bit of a mess. Is there any better way to deal with this? Also the zswap_init_started variable name has always been a bit confusing. If everything around it takes zswap_init_lock now, it can be replaced with a check for successful zswap initialization as all the initializtion is covered by the lock. That would really help to clean up the code. > +static int zswap_debugfs_init(void) > { > if (!debugfs_initialized()) > return -ENODEV; > @@ -1482,7 +1503,7 @@ static int __init zswap_debugfs_init(void) > return 0; > } > #else > -static int __init zswap_debugfs_init(void) > +static int zswap_debugfs_init(void) Is there any reason to not just always initialize debugfs and only defer the expensive allocations?