From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3E1FCA9ECF for ; Fri, 1 Nov 2019 08:57:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8EAB8204FD for ; Fri, 1 Nov 2019 08:57:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8EAB8204FD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 283196B0266; Fri, 1 Nov 2019 04:57:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2332C6B026C; Fri, 1 Nov 2019 04:57:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 149576B026D; Fri, 1 Nov 2019 04:57:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id E96AA6B0266 for ; Fri, 1 Nov 2019 04:57:28 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 815239089 for ; Fri, 1 Nov 2019 08:57:28 +0000 (UTC) X-FDA: 76107104976.22.snake03_5daf0e79be661 X-HE-Tag: snake03_5daf0e79be661 X-Filterd-Recvd-Size: 4102 Received: from huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 1 Nov 2019 08:57:23 +0000 (UTC) Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 64718F688EBCD257D62C; Fri, 1 Nov 2019 16:57:14 +0800 (CST) Received: from [127.0.0.1] (10.133.219.218) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.439.0; Fri, 1 Nov 2019 16:57:10 +0800 Message-ID: <5DBBF366.6020002@huawei.com> Date: Fri, 1 Nov 2019 16:57:10 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Johannes Weiner CC: Minchan Kim , Michal Hocko , , , Subject: Re: [PATCH] mm: fix unevictable page reclaim when calling madvise_pageout References: <1572275317-63910-1-git-send-email-zhongjiang@huawei.com> <20191029081102.GB31513@dhcp22.suse.cz> <5DB806D1.8020503@huawei.com> <20191029094039.GH31513@dhcp22.suse.cz> <5DB81838.6020208@huawei.com> <20191030165239.GA167773@google.com> <20191030172241.GA43851@cmpxchg.org> In-Reply-To: <20191030172241.GA43851@cmpxchg.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.133.219.218] X-CFilter-Loop: Reflected X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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