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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 22EA6C3524B for ; Wed, 5 Feb 2020 01:20:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CF928218AC for ; Wed, 5 Feb 2020 01:20:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WXovHO8A" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF928218AC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5F3576B0003; Tue, 4 Feb 2020 20:20:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A3A36B0005; Tue, 4 Feb 2020 20:20:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46BEB6B0006; Tue, 4 Feb 2020 20:20:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0129.hostedemail.com [216.40.44.129]) by kanga.kvack.org (Postfix) with ESMTP id 2A4B66B0003 for ; Tue, 4 Feb 2020 20:20:28 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B6D69180AD804 for ; Wed, 5 Feb 2020 01:20:27 +0000 (UTC) X-FDA: 76454318094.26.dirt76_5b4bedc714543 X-HE-Tag: dirt76_5b4bedc714543 X-Filterd-Recvd-Size: 6054 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Wed, 5 Feb 2020 01:20:27 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id s18so477948iln.0 for ; Tue, 04 Feb 2020 17:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W0yQGDZerCMtKY6Kjdt1L600+y/8MQHS81Frdz0g8rg=; b=WXovHO8ACtYwJ2he/KBeBhjgslIBnRQ5EwS2/+jmVYGvp08DAoecZKFkcolCZOklhJ zRCGnGNeXTeFQRky6rEv2nL5lQ847Rp1NQD6rM11ILYYezYv3/gSPbfUu64BrJeeMXsP aeiW4beetWmQl8+wf1LJ7WkMJMu37njsSF98eHDzP6EQk0tS5yP3bKTpZCqg69FOh/4a oMUV4U3dA3/8SqkX/QS2iM98s2jiOebndlKVFkwDijzOPMLy2QGSq8OMNgQxe+auPbE/ 73w1KIBRJkO2WjK/sRNDWfBe/noie8TRLJjn5bCG2c0kSzyJO1BOiLO/bmI4WHwFPSmW AX5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W0yQGDZerCMtKY6Kjdt1L600+y/8MQHS81Frdz0g8rg=; b=k3W9FB8X7zOXbltniUHrYxziWAUwxEjrCB+NYV8aQWS7Pl8TEcvzRr5u27w6e2jrsl 1uY/iCAf3QJAXXS0JaUdVQ3BFixdBLI3MqQd4h1d4e/UaxeoZJmgEapSxQs0tfnQ+q+u DDn2N+UhF9X4+iu+SpohBnY19JZOn1IpNIuW5Jy8Z0tF2xSIbXZF9T8pNmlx4jy1VBoN +cVsXK4Vp/ftRUNrM1bY/RY+pHovawHXJ46+ARf5uUEVGSt5M4GQiCYGE3d+RVsG/1p0 1uIhXTBXoUUi4SShQy4dOETzzC4Dqsu/Mi/gqgvOhjHeSNrrl/a9EQNjeSdQS3ffUH/d yEcQ== X-Gm-Message-State: APjAAAWO3UBCtzVc8/qLLYKIvV+KxrYO7DBLqV50we7iHxgYiSgZ72Iz 5sP1K3Zt/zEQvahgZ5JkMcG9dcui5nk0yMn6GGM= X-Google-Smtp-Source: APXvYqyCkFN6Hg1ip9U3BPP5zZB50t/FjZK5mzZsLcv0aqT45pq5jorxFjaRGlfzw47qNmTCz1O2t8U4z7MHpgVlsS0= X-Received: by 2002:a92:c848:: with SMTP id b8mr31751810ilq.168.1580865626631; Tue, 04 Feb 2020 17:20:26 -0800 (PST) MIME-Version: 1.0 References: <1578499437-1664-1-git-send-email-laoar.shao@gmail.com> <20200204211954.GA20584@dread.disaster.area> In-Reply-To: <20200204211954.GA20584@dread.disaster.area> From: Yafang Shao Date: Wed, 5 Feb 2020 09:19:50 +0800 Message-ID: Subject: Re: [PATCH v3 0/3] protect page cache from freeing inode To: Dave Chinner Cc: Dave Chinner , Johannes Weiner , Michal Hocko , Vladimir Davydov , Roman Gushchin , Andrew Morton , Al Viro , Linux MM , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" 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 Wed, Feb 5, 2020 at 5:20 AM Dave Chinner wrote: > > On Wed, Jan 22, 2020 at 09:46:57PM +0800, Yafang Shao wrote: > > On Thu, Jan 9, 2020 at 12:04 AM Yafang Shao wrote: > > > > > > On my server there're some running MEMCGs protected by memory.{min, low}, > > > but I found the usage of these MEMCGs abruptly became very small, which > > > were far less than the protect limit. It confused me and finally I > > > found that was because of inode stealing. > > > Once an inode is freed, all its belonging page caches will be dropped as > > > well, no matter how may page caches it has. So if we intend to protect the > > > page caches in a memcg, we must protect their host (the inode) first. > > > Otherwise the memcg protection can be easily bypassed with freeing inode, > > > especially if there're big files in this memcg. > > > The inherent mismatch between memcg and inode is a trouble. One inode can > > > be shared by different MEMCGs, but it is a very rare case. If an inode is > > > shared, its belonging page caches may be charged to different MEMCGs. > > > Currently there's no perfect solution to fix this kind of issue, but the > > > inode majority-writer ownership switching can help it more or less. > > > > > > - Changes against v2: > > > 1. Seperates memcg patches from this patchset, suggested by Roman. > > > A separate patch is alreay ACKed by Roman, please the MEMCG > > > maintianers help take a look at it[1]. > > > 2. Improves code around the usage of for_each_mem_cgroup(), suggested > > > by Dave > > > 3. Use memcg_low_reclaim passed from scan_control, instead of > > > introducing a new member in struct mem_cgroup. > > > 4. Some other code improvement suggested by Dave. > > > > > > > > > - Changes against v1: > > > Use the memcg passed from the shrink_control, instead of getting it from > > > inode itself, suggested by Dave. That could make the laying better. > > > > > > [1] > > > https://lore.kernel.org/linux-mm/CALOAHbBhPgh3WEuLu2B6e2vj1J8K=gGOyCKzb8tKWmDqFs-rfQ@mail.gmail.com/ > > > > > > Yafang Shao (3): > > > mm, list_lru: make memcg visible to lru walker isolation function > > > mm, shrinker: make memcg low reclaim visible to lru walker isolation > > > function > > > memcg, inode: protect page cache from freeing inode > > > > > > fs/inode.c | 78 ++++++++++++++++++++++++++++++++++++++++++++-- > > > include/linux/memcontrol.h | 21 +++++++++++++ > > > include/linux/shrinker.h | 3 ++ > > > mm/list_lru.c | 47 +++++++++++++++++----------- > > > mm/memcontrol.c | 15 --------- > > > mm/vmscan.c | 27 +++++++++------- > > > 6 files changed, 143 insertions(+), 48 deletions(-) > > > > > > > Dave, Johannes, > > > > Any comments on this new version ? > > Sorry, I lost track of this amongst travel and conferences mid > january. Can you update and post it again once -rc1 is out? > Sure, I will do it. Thanks for your reply. Thanks Yafang