linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: zhong jiang <zhongjiang@huawei.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Minchan Kim <minchan@kernel.org>,
	Michal Hocko <mhocko@kernel.org>, <akpm@linux-foundation.org>,
	<ktkhai@virtuozzo.com>, <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: fix unevictable page reclaim when calling madvise_pageout
Date: Fri, 1 Nov 2019 16:57:10 +0800	[thread overview]
Message-ID: <5DBBF366.6020002@huawei.com> (raw)
In-Reply-To: <20191030172241.GA43851@cmpxchg.org>

On 2019/10/31 1:22, Johannes Weiner wrote:
> On Wed, Oct 30, 2019 at 09:52:39AM -0700, Minchan Kim wrote:
>> @@ -1468,7 +1468,7 @@ static long check_and_migrate_cma_pages(struct task_struct *tsk,
>>  					drain_allow = false;
>>  				}
>>  
>> -				if (!isolate_lru_page(head)) {
>> +				if (!isolate_lru_page(head, false)) {
>>  					list_add_tail(&head->lru, &cma_page_list);
>>  					mod_node_page_state(page_pgdat(head),
>>  							    NR_ISOLATED_ANON +
> It's not clear what that argument means at the callsite, and every
> caller needs to pass it to support one niche usecase. Let's not do
> that.
>
> I think there are better options. Personally, I think it's a good idea
> to keep the sanity check in shrink_page_list() because the mlock LRU
> handling is quite tricky. madvise() is really the odd one out here
> because it isolates LRU pages through page tables and then sends them
> through the regular reclaim path, so IMO it should be the madvise
> proper that handles the exceptional situation.
>
> Why not just this? Maybe with a comment that points out that we're
> coming from the page tables instead of a specific LRU list, and so
> need to filter out the unevictable lru pages from our end.
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 99dd06fecfa9..63e130800570 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -363,8 +363,12 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  		ClearPageReferenced(page);
>  		test_and_clear_page_young(page);
>  		if (pageout) {
> -			if (!isolate_lru_page(page))
> -				list_add(&page->lru, &page_list);
> +			if (!isolate_lru_page(page)) {
> +				if (PageUnevictable(page))
> +					putback_lru_page(page);
> +				else
> +					list_add(&page->lru, &page_list);
> +			}
>  		} else
>  			deactivate_page(page);
>  huge_unlock:
> @@ -441,8 +445,12 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  		ClearPageReferenced(page);
>  		test_and_clear_page_young(page);
>  		if (pageout) {
> -			if (!isolate_lru_page(page))
> -				list_add(&page->lru, &page_list);
> +			if (!isolate_lru_page(page)) {
> +				if (PageUnevictable(page))
> +					putback_lru_page(page);
> +				else
> +					list_add(&page->lru, &page_list);
> +			}
>  		} else
>  			deactivate_page(page);
>  	}
>
> .
>
It seems to filter the Unevictable page is the correct fix.  Even  though I am not very clear how
an little race window to result in an PageMlocked in vmscan. 

I will repost the patch in v2 as you has proposed.  Thanks

Sincerely,
zhong jiang



  parent reply	other threads:[~2019-11-01  8:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 15:08 zhong jiang
2019-10-28 15:27 ` David Hildenbrand
2019-10-28 15:45   ` zhong jiang
2019-10-28 16:07     ` David Hildenbrand
2019-10-28 16:15       ` zhong jiang
2019-10-28 16:15       ` David Hildenbrand
2019-10-29  2:29         ` zhong jiang
2019-10-29  8:11 ` Michal Hocko
2019-10-29  9:30   ` zhong jiang
2019-10-29  9:40     ` Michal Hocko
2019-10-29 10:45       ` zhong jiang
2019-10-30 16:52         ` Minchan Kim
2019-10-30 17:22           ` Johannes Weiner
2019-10-30 18:39             ` Minchan Kim
2019-11-01  8:57             ` zhong jiang [this message]
2019-10-30 17:45           ` Michal Hocko
2019-10-30 18:42             ` Minchan Kim
2019-10-30 19:33             ` Johannes Weiner
2019-10-31  9:16               ` Michal Hocko
2019-10-31 14:48                 ` Minchan Kim
2019-10-31 17:17                   ` Michal Hocko
2019-11-01 12:56                 ` zhong jiang
2019-10-31  9:46               ` 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=5DBBF366.6020002@huawei.com \
    --to=zhongjiang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=ktkhai@virtuozzo.com \
    --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