[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b17caa5f-f3db-9fb0-fe1f-45510ff902c8@huawei.com>
Date: Wed, 14 Jul 2021 19:36:57 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Matthew Wilcox <willy@...radead.org>,
Michal Hocko <mhocko@...e.com>, Yu Zhao <yuzhao@...gle.com>
CC: <akpm@...ux-foundation.org>, <hannes@...xchg.org>,
<vbabka@...e.cz>, <axboe@...nel.dk>, <iamjoonsoo.kim@....com>,
<alexs@...nel.org>, <apopple@...dia.com>, <minchan@...nel.org>,
<david@...hat.com>, <shli@...com>, <hillf.zj@...baba-inc.com>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/5] mm/vmscan: put the redirtied MADV_FREE pages back to
anonymous LRU list
On 2021/7/13 21:34, Matthew Wilcox wrote:
> On Tue, Jul 13, 2021 at 09:13:51PM +0800, Miaohe Lin wrote:
>>>> When the MADV_FREE pages are redirtied before they could be reclaimed, the pages
>>>> should be put back to anonymous LRU list by setting SwapBacked flag, thus the
>>>> pages will be reclaimed in normal swapout way.
>>>
>>> Agreed. But the question is why this needs an explicit handling here
>>> when we already do handle this case when trying to unmap the page.
>>
>> This makes me think more. It seems even the page_ref_freeze call is guaranteed to
>> success as no one can grab the page refcnt after the page is successfully unmapped.
>
> NO! This is wrong. Every page can have its refcount speculatively raised
> (and then lowered). The two prime candidates for this are lockless GUP
> and page cache lookups, but there can be others too.
>
Many thanks for pointing this out. My overlook! Sorry!
So, it seems lockless GUP can redirty the MADV_FREE page. But is it ok to just release
a redirtied MADV_FREE pages? Because we hold the last reference here and the page will
be freed anyway...
> .
>
Powered by blists - more mailing lists