--
Best Regards,
Yan, Zi
On 19 Dec 2024, at 10:56, Bernd Schubert wrote:
> 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?
Both are unmovable, but you can control where FUSE TMP page
can come from to avoid spread across the entire memory space. For example,
allocate a contiguous region as a TMP page pool.
