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
