linux-kernel - Re: [PATCH 3/8] mm/vmscan: introduce helper function reclaim_page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8d29ed79-6160-5766-da95-93dd2de94f52@huawei.com>
Date:   Thu, 31 Mar 2022 09:45:47 +0800
From:   Miaohe Lin <linmiaohe@...wei.com>
To:     Matthew Wilcox <willy@...radead.org>
CC:     <akpm@...ux-foundation.org>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/8] mm/vmscan: introduce helper function
 reclaim_page_list()

On 2022/3/31 0:23, Matthew Wilcox wrote:
> On Wed, Mar 30, 2022 at 10:04:54AM +0800, Miaohe Lin wrote:
>> On 2022/3/29 21:50, Matthew Wilcox wrote:
>>>> +	while (!list_empty(page_list)) {
>>>> +		page = lru_to_page(page_list);
>>>> +		list_del(&page->lru);
>>>> +		putback_lru_page(page);
>>>
>>> Why wouldn't you use a folio here?
>>>
>>
>> I was just wanting to keep the code consistent with the previous one. Am I supposed to
>> use a folio here ? If so, will do it in V2.
> 
> The distinction we're trying to make (and obviously we have a long way
> to go before we're finished) is between the structure that describes
> PAGE_SIZE bytes of memory and the structure that manages the memory
> allocation.  This function is clearly handling the entire memory
> allocation, so it should be using a folio.  Eventually, page->lru

I see. Thanks for clarifying.

> should disappear, but there's 180 places to figure out what we need to
> do instead.
> 
> 
> .
>