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;
Date:   Thu, 4 May 2023 07:53:18 -0700
From:   Chris Li <chrisl@kernel.org>
To:     Liu Shixin <liushixin2@huawei.com>
Cc:     Seth Jennings <sjenning@redhat.com>,
        Dan Streetman <ddstreet@ieee.org>,
        Vitaly Wool <vitaly.wool@konsulko.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org
Subject: Re: [PATCH -next v9 0/3] Delay the initialization of zswap
Message-ID: <ZFPG3swMcHW/qxID@google.com>
References: <20230411093632.822290-1-liushixin2@huawei.com>
 <ZFL4Tvm8KKrCfjRr@google.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>
Precedence: bulk

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