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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 E37AEC35247 for ; Tue, 4 Feb 2020 21:20:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9B242082E for ; Tue, 4 Feb 2020 21:20:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9B242082E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 396C26B0005; Tue, 4 Feb 2020 16:20:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 348666B0006; Tue, 4 Feb 2020 16:20:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25D076B0007; Tue, 4 Feb 2020 16:20:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id 0E43E6B0005 for ; Tue, 4 Feb 2020 16:20:02 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8E77E181AEF00 for ; Tue, 4 Feb 2020 21:20:01 +0000 (UTC) X-FDA: 76453712202.14.event56_1d39150d4473d X-HE-Tag: event56_1d39150d4473d X-Filterd-Recvd-Size: 4792 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Feb 2020 21:20:00 +0000 (UTC) Received: from dread.disaster.area (pa49-181-161-120.pa.nsw.optusnet.com.au [49.181.161.120]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 4E9EC3A2B57; Wed, 5 Feb 2020 08:19:55 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1iz5bu-0005hq-5b; Wed, 05 Feb 2020 08:19:54 +1100 Date: Wed, 5 Feb 2020 08:19:54 +1100 From: Dave Chinner To: Yafang Shao Cc: Dave Chinner , Johannes Weiner , Michal Hocko , Vladimir Davydov , Roman Gushchin , Andrew Morton , Al Viro , Linux MM , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 0/3] protect page cache from freeing inode Message-ID: <20200204211954.GA20584@dread.disaster.area> References: <1578499437-1664-1-git-send-email-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=W5xGqiek c=1 sm=1 tr=0 a=SkgQWeG3jiSQFIjTo4+liA==:117 a=SkgQWeG3jiSQFIjTo4+liA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=pGLkceISAAAA:8 a=VwQbUJbxAAAA:8 a=7-415B0cAAAA:8 a=Sa-qTvfxgUUOiSiq2jIA:9 a=CjuIK1q_8ugA:10 a=AjGcO6oz07-iQ99wixmX:22 a=biEYGPWJfzWAr4FL6Ov7:22 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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? Cheers, Dave. -- Dave Chinner david@fromorbit.com