From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08DBCC77B78 for ; Thu, 4 May 2023 00:12:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24F026B0075; Wed, 3 May 2023 20:12:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D7F16B007B; Wed, 3 May 2023 20:12:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A0406B0080; Wed, 3 May 2023 20:12:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by kanga.kvack.org (Postfix) with ESMTP id E3F346B0075 for ; Wed, 3 May 2023 20:12:00 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 90B5462D6C; Thu, 4 May 2023 00:12:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4AC0C433EF; Thu, 4 May 2023 00:11:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683159120; bh=7vQ5LtU82wHXy4yqeGR03FmQei9dn4hIyS7S4R5ZW4w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gp1mKLKJrv+lOUYMAgOQ2vCR+mAWQ1yUjC+1eZMv6423cUtI/pqYxKQmbxUz6xMNB HBZa+gd0cYPefotDmhuRUOUb/BYglfd4aEikWoR2aT3HGtNAoZIpfGYZVDiMZOMlJh VnfBcAUQMpx0NFoQU+ek65mAiDwJ1YM3EpgFMXRa3w2Krrqjv1CEgd7bn/7hAbQlks B5b05e1egjpTqgyb99INaR4/OrXJUDxD6HixJthRdi6FN6ldYzL/sQfnh+QMVqM/DE miTpi37l+6I+bYeO42zdpC60AKQyJPNehJraaEX0LBlXYS9IvFmXKPBHZXFyf6THLY G1++9/5+L1jsg== Date: Wed, 3 May 2023 17:11:58 -0700 From: Chris Li 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 v9 0/3] Delay the initialization of zswap Message-ID: References: <20230411093632.822290-1-liushixin2@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411093632.822290-1-liushixin2@huawei.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Shixing, On Tue, Apr 11, 2023 at 05:36:29PM +0800, Liu Shixin wrote: > In the initialization of zswap, about 18MB memory will be allocated for > zswap_pool. Since some users may not use zswap, the zswap_pool is wasted. > Save memory by delaying the initialization of zswap until enabled. Sorry I am late to this discussion. I notice you are already at V9. Anyway, I am curious how much of the 18MB was came from the zswap_pool alone and how much of it came from the other part of the initialization. If it is the zswap_pool alone, it means that we can have a smaller patch to get most of your 18M back. I also notice you move a lot of __init function back to normal functions. That would mean those functions wouldn't be able to drop after the initialization phase. That is another reason to move less of the initialization function. Chris