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, 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? The only workaround I can see for the splice case that doesn't resort to bringing back extra copies is to have splice somehow ensure that the page isn't being migrated when it's accessing it. Thanks, Joanne > > Just throwing it out there ... no expert at all on fuse ... > > -- > Cheers, > > David / dhildenb >
