From: Charan Teja Kalla <charante@codeaurora.org>
To: Suren Baghdasaryan <surenb@google.com>
Cc: hughd@google.com, akpm@linux-foundation.org, vbabka@suse.cz,
rientjes@google.com, david@redhat.com, mhocko@suse.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kirill.shutemov@linux.intel.com, rppt@linux.vnet.ibm.com,
guptap@codeaurora.org
Subject: Re: [PATCH] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem
Date: Wed, 3 Nov 2021 18:11:00 +0530 [thread overview]
Message-ID: <1ef89af2-43a4-415c-3c8b-97dca429a416@codeaurora.org> (raw)
In-Reply-To: <CAJuCfpEy7UCD6C9OyxzDFV-4AOj7-QQEZa4KXJwZer2BkBnO+g@mail.gmail.com>
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
prev parent reply other threads:[~2021-11-03 12:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 14:06 [PATCH] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem Charan Teja Reddy
2021-10-25 14:17 ` Charan Teja Kalla
2021-10-28 18:40 ` Suren Baghdasaryan
2021-11-01 14:40 ` Charan Teja Kalla
2021-11-02 18:12 ` Suren Baghdasaryan
2021-11-03 12:41 ` Charan Teja Kalla [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ef89af2-43a4-415c-3c8b-97dca429a416@codeaurora.org \
--to=charante@codeaurora.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=guptap@codeaurora.org \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.