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 B8553C7EE23 for ; Thu, 4 May 2023 14:53:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD92F6B0072; Thu, 4 May 2023 10:53:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B89A16B007D; Thu, 4 May 2023 10:53:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9F526B007E; Thu, 4 May 2023 10:53:22 -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 968B36B0072 for ; Thu, 4 May 2023 10:53:22 -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 0BB2A634CD; Thu, 4 May 2023 14:53:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D084C433EF; Thu, 4 May 2023 14:53:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683212001; bh=JtHqAGboykoAImyeKUt8Zs/yjaM1bIcB2ckLW3b0W9c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AUCjHN5Q6rOzRLlP9q72SQRY49uwCXZO+3dVjy/S3qRxQZf50fdET8ACBkDf2F/e2 tTSSBi1r1lIOxQHEQEY6H+xvRkp9Ikk29ZDJ/eneqKY8Pu8RmgH6o/451+cM9cGWLU W9CtZCEbN3AIr02jLo9PEjjJ0P+rMCtiLeaUPtheuLAR0MhcVB/iehGq7WFJk6M6AU QMgWe5ZlFBYJ2tj85OAc6M/5ZQGAqY94o2/B1QU2iSDpkSMj78dMfJmt98R7Ta4kl6 ge4Kmr3yPzBFGqnJNwCajeBkpIBKeDGlYVoNHTZYDKUVxk54PfNXbzLLmwY+QyWYo0 oJbppP2vdCSGw== Date: Thu, 4 May 2023 07:53:18 -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> <9b2b6dac-9a3d-efcb-9706-44f6df1fe2bf@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9b2b6dac-9a3d-efcb-9706-44f6df1fe2bf@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: On Thu, May 04, 2023 at 03:11:05PM +0800, Liu Shixin wrote: > > > > If it is the zswap_pool alone, it means that we can have a smaller patch > > to get most of your 18M back. > You're right, the most came from zswap_pool. Thanks for the confirmation. > > 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. > Thanks for your advice. I've thought about it before, but I thought there is less impact > for the size of kernel, so I didn't do it. Let's first agree on the hypothetical patch that only delaying zswap_pool would have the benefit over V9 on: - smaller patch, less invasive. - less kernel text area due to more __init function got free after initialization. If we can reach that agreement, then we can discuss how we can get there. I think there is a possibility that the delay initialization of zswap_pool can fall into the "zswap_has_pool = false" case, so you don't need to have the initialization mutex.  Simpler. I have my selfish reason as well. I have a much larger pending patch against the zswap code so the smaller patch would mean less conflict for me. I am guilty of giving this feedback late. If you come up with a V10, I will be glad to review it. Or, if you prefer, I can come up with the smaller patch for you to review as well. What do you say? Chris