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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/22/24 12:23 AM, David Hildenbrand wrote:
> 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.
> 

But that (memory compaction on memory allocation, which can be triggered
in the fuse server process context) only triggers MIGRATE_SYNC_LIGHT,
which won't wait for writeback.

AFAICS, MIGRATE_SYNC can be triggered during cma allocation, memory
offline, or node compaction manually through sysctl.

-- 
Thanks,
Jingbo




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux