On 12/19/24 16:55, Zi Yan wrote:
> On 19 Dec 2024, at 10:53, Shakeel Butt wrote:
>
>> On Thu, Dec 19, 2024 at 04:47:18PM +0100, David Hildenbrand wrote:
>>> On 19.12.24 16:43, Shakeel Butt wrote:
>>>> On Thu, Dec 19, 2024 at 02:05:04PM +0100, 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@xxxxxxxxx>
>>>>>> Reviewed-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>
>>>>>> ---
>>>>>> 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.
>>>>
>>>> The page under writeback are already unmovable while they are under
>>>> writeback. This patch is only making potentially unrelated tasks to
>>>> synchronously wait on writeback completion for such pages which in worst
>>>> case can be indefinite. This actually is solving an isolation issue on a
>>>> multi-tenant machine.
>>>>
>>> Are you sure, because I read in the cover letter:
>>>
>>> "In the current FUSE writeback design (see commit 3be5a52b30aa ("fuse:
>>> support writable mmap"))), a temp page is allocated for every dirty
>>> page to be written back, the contents of the dirty page are copied over to
>>> the temp page, and the temp page gets handed to the server to write back.
>>> This is done so that writeback may be immediately cleared on the dirty
>>> page,"
>>>
>>> Which to me means that they are immediately movable again?
>>
>> Oh sorry, my mistake, yes this will become an isolation issue with the
>> removal of the temp page in-between which this series is doing. I think
>> the tradeoff is between extra memory plus slow write performance versus
>> temporary unmovable memory.
>
> No, the tradeoff is slow FUSE performance vs whole system slowdown due to
> memory fragmentation. AS_WRITEBACK_INDETERMINATE indicates it is not
> temporary.
Is there is a difference between FUSE TMP page being unmovable and
AS_WRITEBACK_INDETERMINATE folios/pages being unmovable?
Thanks,
Bernd
AS_WRITEBACK_INDETERMINATE
