On 11/10/2025 7:58 PM, Matthew Wilcox wrote:
> On Mon, Nov 10, 2025 at 07:50:17PM +0530, Garg, Shivank wrote:
>> The issue is copying those binary to a freshly mounted filesystem.
>> The page cache folios remain dirty until background writeback completes.
>>
>> Reproduces 100% for me: fresh XFS/EXT4 mount -> copy binary -> execute ->
>> MADV_COLLAPSE fails.
>
> Yes, but this is an uncommon thing to do. Really, it's the kind of
> thing you do when you're testing something (like, whether ext4 supports
> large folios, and whether that yields a performance improvement).
> It's more reasonable to change userspace than the kernel to solve this
> problem you're having.
Fair point.
You're right that this is primarily a testing scenario, though it may also
potentially affect JIT compilers writing executables (also uncommon) but more
research is needed.
For userspace workarounds, calling fsync() before MADV_COLLAPSE works.
Synchronous writeback in MADV_COLLAPSE seems reasonable given it's already
a blocking operation. Alternatively, dropping this patch and keeping only
patch 2 also works for me. As for user sanity, returning -EAGAIN instead
of -EINVAL and some documentation would be beneficial.
Happy to go with whichever approach you think is most appropriate.
Thanks,
Shivank
