On 12/21/24 2:01 AM, Shakeel Butt wrote: > On Fri, Dec 20, 2024 at 03:49:39PM +0100, 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 :( > > Just to be clear AS_WRITEBACK_INDETERMINATE is being used in two core-mm > parts. First is reclaim and second is compaction/migration. For reclaim, > it is a must have as explained by Jingbo in [1] i.e. due to potential > self deadlock by fuse server. If I understand you correctly, the main > concern you have is its usage in the second case. > > The reason for adding AS_WRITEBACK_INDETERMINATE in the second case was > to avoid untrusted fuse server causing pain to unrelated jobs on the > machine (fuse folks please correct me if I am wrong here). Right, IIUC direct MIGRATE_SYNC migration won't be triggered on the memory allocation path, i.e. the fuse server itself won't stumble into MIGRATE_SYNC migration. -- Thanks, Jingbo
