On 08/08/26 22:32, Zi Yan wrote:
On Fri Aug 7, 2026 at 5:22 PM EDT, Kairui Song wrote:
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
I agree. I wonder if it is possible that a shmem in swapcache could
enter non uniform split, folio_split(). With Patch 1,
folio_check_splittable() will return -EINVAL, causing a WARN.
Hi Shivam,
Can you check the above issue? If it is possible, we want to avoid it.
let me know how you think about that RFC.
Sure, will take a look.
Hi Zi,
I checked the current folio_split() callers and this does not seem
possible.
The shmem swapout path unmaps the folio before clearing folio->mapping,
with the folio locked. The non-uniform split callers either get the folio
from an address_space or from a present page-table entry, so they cannot
find a mappingless shmem folio in swapcache.
The memory-failure path uses split_huge_page_to_order(), which performs a
uniform split.
So I don't think the WARN is reachable with the current callers.
Thanks,
Shivam
