On 8/26/2022 2:46 AM, Matthew Wilcox wrote: >>> Looks like my analysis from yesterday was dropped: >>> >>> : This all seems quite plausible. The reproducer seems to (correct me >>> : if I'm wrong) create an AF_PACKET socket and mmap it. af_packet.c >>> : seems to create compound pages and mmap them. This isn't folio-related >>> : at all; I just moved the code that warns about it from mm/vmscan.c to >>> : folio-compat.c. >>> : >>> : Looks like a long-standing bug in MADV_PAGEOUT to me. >> Such page should never be on lru, right? We could test lru before >> calling isolate_lru_page() for this case? I know isolate_lru_page() >> does the check, but the tail page warning is raised before the check. >> >> Could the tail page warning be moved under the lru flag test? Seems >> possible, but it should need extra handling (re-set lru flag). Seems a >> little bit overkilling. > There's a number of ways of solving this. I'm interested in seeing > which one Minchan thinks is best. > My understanding is: PageTransCompound() return false for compound page if THP is disabled in kernel config. Replacing PageTransCompound() with PageCompound() could work here. But for the long term, folio should be the answer. :). Regards Yin, Fengwei
