[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1ef89af2-43a4-415c-3c8b-97dca429a416@codeaurora.org>
Date: Wed, 3 Nov 2021 18:11:00 +0530
From: Charan Teja Kalla <charante@...eaurora.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: hughd@...gle.com, akpm@...ux-foundation.org, vbabka@...e.cz,
rientjes@...gle.com, david@...hat.com, mhocko@...e.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
kirill.shutemov@...ux.intel.com, rppt@...ux.vnet.ibm.com,
guptap@...eaurora.org
Subject: Re: [PATCH] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem
Thanks Suren for the reply!!
On 11/2/2021 11:42 PM, Suren Baghdasaryan wrote:
>>> Also not sure if you need to isolate the page before this writeback.
>> Isolation may not be required but this is to avoid trying of the reclaim
>> on the same page in some parallel path as both any way places the page
>> in the swap. Or you want me to remove the isolation here?
> Maybe you could isolate them in bulk then? Seems like a waste
> isolating them one-by-one.
Okay. Should the bulk here be SWAP_CLUSTER_MAX fine?
>
>>> Won't deleting the page from swap cache interfere with ongoing
>>> writeback if it has not yet completed?
>> I just followed the path of how to reclaim the page:
>> shrink_page_list()
>> pageout()
>> ..........
>> __remove_mapping()
>> __delete_from_swap_cache()
>>
>> You see some issue here which I can't understand.
> I think shrink_page_list() would not call __remove_mapping() if after
> pageout() PageWriteback() is still true. Maybe I'm missing some path?
I agree here. PG_writeback might have still set on the pages under
background writeback thus should be excluded.
I just considered the case for sync writes, eg:zram, where PG_writeback
is cleared before returns.
Will update the change accordingly.
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
Powered by blists - more mailing lists