Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings

[David Hildenbrand <david@redhat.com>]

>> I'm wondering if there would be a way to just "cancel" the writeback and
>> mark the folio dirty again. That way it could be migrated, but not
>> reclaimed. At least we could avoid the whole AS_WRITEBACK_INDETERMINATE
>> thing.
>>
> 
> That is what I basically meant with short timeouts. Obviously it is not
> that simple to cancel the request and to retry - it would add in quite
> some complexity, if all the issues that arise can be solved at all.

At least it would keep that out of core-mm.

AS_WRITEBACK_INDETERMINATE really has weird smell to it ... we should 
try to improve such scenarios, not acknowledge and integrate them, then 
work around using timeouts that must be manually configured, and ca 
likely no be default enabled because it could hurt reasonable use cases :(

Right now we clear the writeback flag immediately, indicating that data 
was written back, when in fact it was not written back at all. I suspect 
fsync() currently handles that manually already, to wait for any of the 
allocated pages to actually get written back by user space, so we have 
control over when something was *actually* written back.


Similar to your proposal, I wonder if there could be a way to request 
fuse to "abort" a writeback request (instead of using fixed timeouts per 
request). Meaning, when we stumble over a folio that is under writeback 
on some paths, we would tell fuse to "end writeback now", or "end 
writeback now if it takes longer than X". Essentially hidden inside 
folio_wait_writeback().

When aborting a request, as I said, we would essentially "end writeback" 
and mark the folio as dirty again. The interesting thing is likely how 
to handle user space that wants to process this request right now (stuck 
in fuse_send_writepage() I assume?), correct?

Just throwing it out there ... no expert at all on fuse ...

-- 
Cheers,

David / dhildenb