On 8/7/26 23:22, Kairui Song wrote: > On Fri, Aug 07, 2026 at 10:18:05AM +0800, Zi Yan wrote: >> On Wed Aug 5, 2026 at 11:54 AM EDT, Kairui Song wrote: >>> >>> Thanks for the CC, this is actually not hard to implement as shown by >>> Shivam, I just found the code more and more hard to follow and fragile >>> as we add more logic to it. And we don't have to reject higher order >>> split either which can be seen easily if the code is cleaner. >>> >>> Personally I think doing some cleanup first is better, I haven't post any >>> code as right now there doesn't seem to be much user of this. It will be >>> needed if more clean THP swapcache begin to show up due to things like >>> THP readahead for swap, which isn't here yet. I think I can send an RFC >>> tomorrow just for reference. I'm fine if we prefer to remove that TODO >>> using this smaller change first :) >> >> Thanks. Can you also help review this patchset? The changes looks good >> to me but I am not sure if I get all the details about swapcache handling. >> >> -- >> Best Regards, >> Yan, Zi > > Hello, > > Thanks for the reminder, I got a bit busy so delayed for a day on that > RFC. > > For this series I think it's functionally fine, just the split logic is > a bit complex to follow and we still have restriction on swap cache > for order 0 uniform split only. I'll have a closer look later. Also > let me know how you think about that RFC.
How does this patch set relate to your split cleanups? Is it still applicable independently? -- Cheers, David
