Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2857957pxv; Mon, 12 Jul 2021 03:45:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHKXhrsIZ87kfcNfyX2XAnGZSUDgo/p1RAKH9D6huV+WXEBsPgLAOaqJii0E2W1unaqi5i X-Received: by 2002:a17:906:844:: with SMTP id f4mr21938525ejd.78.1626086704383; Mon, 12 Jul 2021 03:45:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626086704; cv=none; d=google.com; s=arc-20160816; b=QeXSSerngpNG2tPzMjbsRWyQvHrSX513X49CJlakHeqEKbql/FzngM/yOvfi33L6lG 1Cafi6zlnG0ubxyJ9P52x/GUoU8/Zp0ZJUfDGNaNskBYelLTB4kaQSkiHcVkM9qBdm0P yz9r2EATH/hlxsLF1dHDahSJSCOECMVCkRAr7eooKdDNKHD29zYmdsgGsUnezbLj2vxM SaloPbQC1M/oJELiSKeuQ0dA0rtp0sYJL8XNBMWwtSS7TRxEspvwoIDxNyj635MW6HqK VlTYAQrDi/YdY20w2EpU/u/Uq9zUSqMOGo2ki8AIl+3now+F/r2uRN8gTBh/ev6ZZXS0 UcnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=St2y2Q3qreJ6a5QlQroVe3zQYLCK1Y7cZrN0zcaRTuY=; b=SK42teaQgCyKICUZGiIaUE41lmuHWZnw5KWf3pbsgHwWUZA/kfFaCaCfjovYt4okzr L7sBB+9WFeg5DqmoXOmZMNClPtaiT0PiQXd/3LN97DnlS9Nh3LifGhoTHzTardjeYmJw 6cu4cRROZFFeG8NgXandYHUjXA9RZV/loKLKnbYY1Z3JnBSGn+JYCAG8Lk/X1K+MGOqY nNvTw5JAa6/bQg71Q4PnRjNExDeWtpKb8u3BwIAwgZFhxISpVowSgLnyhf4P/AUO9f5i t2X4UY8l452uOAbqRrxDc+ynhWoBo6zNMRQnRLOM7A+LlzxufEtrur4oxvkStO+k5lNT mSsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h14si8736233ejx.283.2021.07.12.03.44.41; Mon, 12 Jul 2021 03:45:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347157AbhGLHtX (ORCPT + 99 others); Mon, 12 Jul 2021 03:49:23 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:10355 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241589AbhGLHOs (ORCPT ); Mon, 12 Jul 2021 03:14:48 -0400 Received: from dggeme703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4GNZb64GP0z78WH; Mon, 12 Jul 2021 15:07:30 +0800 (CST) Received: from [10.174.178.125] (10.174.178.125) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Mon, 12 Jul 2021 15:11:56 +0800 Subject: Re: [PATCH 1/5] mm/vmscan: put the redirtied MADV_FREE pages back to anonymous LRU list To: Yu Zhao CC: , , , , , , , , , , , , , , References: <20210710100329.49174-1-linmiaohe@huawei.com> <20210710100329.49174-2-linmiaohe@huawei.com> From: Miaohe Lin Message-ID: <022f2f7c-fc03-182a-1f8f-4b77c0731d4f@huawei.com> Date: Mon, 12 Jul 2021 15:11:55 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.125] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggeme703-chm.china.huawei.com (10.1.199.99) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/7/11 7:22, Yu Zhao wrote: > On Sat, Jul 10, 2021 at 4:03 AM Miaohe Lin wrote: >> >> If the MADV_FREE pages are redirtied before they could be reclaimed, put >> the pages back to anonymous LRU list by setting SwapBacked flag and the >> pages will be reclaimed in normal swapout way. Otherwise MADV_FREE pages >> won't be reclaimed as expected. >> >> Fixes: 802a3a92ad7a ("mm: reclaim MADV_FREE pages") > > This is not a bug -- the dirty check isn't needed but it was copied > from __remove_mapping(). Yes, this is not a bug and harmless. When we reach here, page should not be dirtied because PageDirty is handled above and there is no way to redirty it again as pagetable references are all gone and it's not in the swap cache. > > The page has only one reference left, which is from the isolation. > After the caller puts the page back on lru and drops the reference, > the page will be freed anyway. It doesn't matter which lru it goes. But it looks buggy as it didn't perform the expected ops from code view. Should I drop the Fixes tag and send a v2 version? Many thanks for reply! > >> Signed-off-by: Miaohe Lin >> --- >> mm/vmscan.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index a7602f71ec04..6483fe0e2065 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -1628,6 +1628,7 @@ static unsigned int shrink_page_list(struct list_head *page_list, >> if (!page_ref_freeze(page, 1)) >> goto keep_locked; >> if (PageDirty(page)) { >> + SetPageSwapBacked(page); >> page_ref_unfreeze(page, 1); >> goto keep_locked; >> } >> -- >> 2.23.0 >> >> > . >