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 > > . >
