From: zhong jiang <zhongjiang@huawei.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: <akpm@linux-foundation.org>, <minchan@kernel.org>,
<hannes@cmpxchg.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH v3] mm: fix trying to reclaim unevictable lru page when calling madvise_pageout
Date: Tue, 5 Nov 2019 20:28:58 +0800 [thread overview]
Message-ID: <5DC16B0A.6070605@huawei.com> (raw)
In-Reply-To: <20191105063353.GE22672@dhcp22.suse.cz>
On 2019/11/5 14:33, Michal Hocko wrote:
> On Sat 02-11-19 15:36:55, zhong jiang wrote:
>> On 2019/11/2 2:32, Michal Hocko wrote:
> [...]
>>> But I would really appreciate to add a comment for the BUG_ON and
>>> explain why do we care about PageUnevictable so much when there is an
>>> explicit page_evictable check in the reclaim path. In other words a
>>> short summary of what Johannes explained in
>>> http://lkml.kernel.org/r/20191030193307.GA48128@cmpxchg.org. Maybe in a
>>> separate patch. Care to send one or should I send it?
>> Hi, Michal
>>
>> Actually, I am not very clear about the words Johannes had said. How the race to
>> tirgger, it will result in an PgeMlocked page can be visible in shrink_page_list.
>>
>> Could you elaborate the race in detail further ?
> I would go with the following comment
>
> /*
> * Page reclaim can see !page_evictable(), but it must not see pages that
> * have the PageUnevictable lru bit already set. See __pagevec_lru_add_fn()
> * for more details.
> */
But the detail still confuses me in __pagevec_lru_add_fn() to see PageMlocked in vmscan :-\ .
next prev parent reply other threads:[~2019-11-05 12:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 13:50 zhong jiang
2019-11-01 14:46 ` Johannes Weiner
2019-11-01 15:08 ` Minchan Kim
2019-11-01 18:32 ` Michal Hocko
2019-11-02 7:36 ` zhong jiang
2019-11-05 6:33 ` Michal Hocko
2019-11-05 12:28 ` zhong jiang [this message]
2019-11-05 12:45 ` Michal Hocko
2019-11-05 14:10 ` zhong jiang
2019-11-05 18:48 ` Johannes Weiner
2019-11-07 13:31 ` zhong jiang
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=5DC16B0A.6070605@huawei.com \
--to=zhongjiang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox