On 20.12.24 22:01, Joanne Koong wrote:
On Fri, Dec 20, 2024 at 6:49 AM David Hildenbrand <david@xxxxxxxxxx> 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.
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?
This would be fine if the writeback request hasn't been sent yet to
userspace but if it has and the pages are spliced
Can you point me at the code where that splicing happens?
, then ending
writeback could lead to memory crashes if the pipebuf buf->page is
accessed as it's being migrated. When a page/folio is being migrated,
is there some state set on the page to indicate that it's currently
under migration?
Unfortunately not really. It should be isolated and locked. So it would
be a !LRU but locked folio.
--
Cheers,
David / dhildenb
