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

[Bernd Schubert <bernd.schubert@fastmail.fm>]

On 12/20/24 15:49, David Hildenbrand wrote:
>>> 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.

Yeah, fuse_writepage_end() decreases fi->writectr, which gets checked
by fsync.

Knowing when somethings has been written back is not the issue, but
keeping order, handling splice, possible double write to the same range
(it should be mostly idempotent, but is that guaranteed by all servers),
etc.


> 
> 
> 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().

Yeah, that would be a minor improvement to the overall issue ;) Re-queue
issue.

> 
> 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?

That sends background requests - does not get stuck. Completion happens
in fuse_writepage_end(), when the request reply is received.



Thanks,
Bernd