linux-kernel - Re: [PATCH -next v9 0/3] Delay the initialization of zswap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6ed055cb-e705-3993-6285-3a30bba15c0d@huawei.com>
Date:   Mon, 8 May 2023 09:37:23 +0800
From:   Liu Shixin <liushixin2@...wei.com>
To:     Chris Li <chrisl@...nel.org>
CC:     Seth Jennings <sjenning@...hat.com>,
        Dan Streetman <ddstreet@...e.org>,
        Vitaly Wool <vitaly.wool@...sulko.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Christoph Hellwig <hch@....de>, <linux-kernel@...r.kernel.org>,
        <linux-mm@...ck.org>
Subject: Re: [PATCH -next v9 0/3] Delay the initialization of zswap



On 2023/5/4 22:53, Chris Li wrote:
> 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?
You can add a pre-patch to modify it before your patch. Thanks.
>
> Chris
>
> .
>