On 21.12.24 03:28, Jingbo Xu wrote:
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.
Maybe memory compaction (on higher-order allocations only) could trigger it?
gfp_compaction_allowed() checks __GFP_IO. GFP_KERNEL includes that.
--
Cheers,
David / dhildenb
