[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bfae7d17-eb50-55b1-1275-5ba0f86a5273@redhat.com>
Date: Tue, 1 Mar 2022 17:22:08 +0100
From: David Hildenbrand <david@...hat.com>
To: Felix Kuehling <felix.kuehling@....com>,
Alex Sierra <alex.sierra@....com>, jgg@...dia.com
Cc: linux-mm@...ck.org, rcampbell@...dia.com,
linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
hch@....de, jglisse@...hat.com, apopple@...dia.com,
willy@...radead.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] mm: split vm_normal_pages for LRU and non-LRU handling
>>
>>> if (PageReserved(page))
>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>> index c31d04b46a5e..17d049311b78 100644
>>> --- a/mm/migrate.c
>>> +++ b/mm/migrate.c
>>> @@ -1614,7 +1614,7 @@ static int add_page_for_migration(struct mm_struct *mm, unsigned long addr,
>>> goto out;
>>>
>>> /* FOLL_DUMP to ignore special (like zero) pages */
>>> - follflags = FOLL_GET | FOLL_DUMP;
>>> + follflags = FOLL_GET | FOLL_DUMP | FOLL_LRU;
>>> page = follow_page(vma, addr, follflags);
>> Why wouldn't we want to dump DEVICE_COHERENT pages? This looks wrong.
>
> This function later calls isolate_lru_page, which is something you can't
> do with a device page.
>
Then, that code might require care instead. We most certainly don't want
to have random memory holes in a dump just because some anonymous memory
was migrated to DEVICE_COHERENT.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists