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

[Zi Yan <ziy@nvidia.com>]

On 19 Dec 2024, at 10:39, David Hildenbrand wrote:

> On 19.12.24 16:08, Zi Yan wrote:
>> On 19 Dec 2024, at 9:19, Zi Yan wrote:
>>
>>> On 19 Dec 2024, at 8:05, David Hildenbrand wrote:
>>>
>>>> On 23.11.24 00:23, Joanne Koong wrote:
>>>>> For migrations called in MIGRATE_SYNC mode, skip migrating the folio if
>>>>> it is under writeback and has the AS_WRITEBACK_INDETERMINATE flag set on its
>>>>> mapping. If the AS_WRITEBACK_INDETERMINATE flag is set on the mapping, the
>>>>> writeback may take an indeterminate amount of time to complete, and
>>>>> waits may get stuck.
>>>>>
>>>>> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
>>>>> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
>>>>> ---
>>>>>    mm/migrate.c | 5 ++++-
>>>>>    1 file changed, 4 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>>>> index df91248755e4..fe73284e5246 100644
>>>>> --- a/mm/migrate.c
>>>>> +++ b/mm/migrate.c
>>>>> @@ -1260,7 +1260,10 @@ static int migrate_folio_unmap(new_folio_t get_new_folio,
>>>>>    		 */
>>>>>    		switch (mode) {
>>>>>    		case MIGRATE_SYNC:
>>>>> -			break;
>>>>> +			if (!src->mapping ||
>>>>> +			    !mapping_writeback_indeterminate(src->mapping))
>>>>> +				break;
>>>>> +			fallthrough;
>>>>>    		default:
>>>>>    			rc = -EBUSY;
>>>>>    			goto out;
>>>>
>>>> Ehm, doesn't this mean that any fuse user can essentially completely block CMA allocations, memory compaction, memory hotunplug, memory poisoning... ?!
>>>>
>>>> That sounds very bad.
>>>
>>> Yeah, these writeback folios become unmovable. It makes memory fragmentation
>>> unrecoverable. I do not know why AS_WRITEBACK_INDETERMINATE is allowed, since
>>> it is essentially a forever pin to writeback folios. Why not introduce a
>>> retry and timeout mechanism instead of waiting for the writeback forever?
>>
>> If there is no way around such indeterminate writebacks, to avoid fragment memory,
>> these to-be-written-back folios should be migrated to a physically contiguous region. Either you have a preallocated region or get free pages from MIGRATE_UNMOVABLE.
>
> But at what point?

Before each writeback. And there should be a limit on the amount of unmovable
pages they can allocate.

>
> We surely don't want to make fuse consume only effectively-unmovable memory.

Yes, that is undesirable, but the folio under writeback cannot be migrated,
since migration needs to wait until its finish. Of course, the right way
is to make writeback interruptible, so that migration can continue, but
that routine might take a lot of effort I suppose. I admit my proposal is more
like a bandaid to minimize the memory fragmentation issue.

--
Best Regards,
Yan, Zi