From patchwork Sun Feb 23 09:31:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 11398741 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B2355924 for ; Sun, 23 Feb 2020 09:32:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 62D9A208C3 for ; Sun, 23 Feb 2020 09:32:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="sCYEsVwj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62D9A208C3 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 B98376B0005; Sun, 23 Feb 2020 04:32:02 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id B49606B0006; Sun, 23 Feb 2020 04:32:02 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A11D96B0007; Sun, 23 Feb 2020 04:32:02 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id 85F316B0005 for ; Sun, 23 Feb 2020 04:32:02 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3B0204417 for ; Sun, 23 Feb 2020 09:32:02 +0000 (UTC) X-FDA: 76520875284.14.push29_2ed2400b27226 X-Spam-Summary: 2,0,0,c0bdeb0f842b4b6c,d41d8cd98f00b204,laoar.shao@gmail.com,,RULES_HIT:41:69:355:379:541:800:965:966:967:973:988:989:1260:1345:1437:1535:1542:1711:1730:1747:1777:1792:2196:2199:2393:2525:2553:2559:2563:2682:2685:2693:2859:2895:2897:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4385:4390:4395:4470:4605:5007:6119:6261:6653:7875:7903:9025:9413:10004:11026:11232:11658:11914:12043:12048:12291:12296:12297:12517:12519:12555:12663:12679:12683:12986:13161:13229:14181:14394:14687:14721:21080:21444:21450:21451:21627:21666:21749:21811:21972:30012:30026:30054:30070:30090,0,RBL:209.85.215.196:@gmail.com:.lbl8.mailshell.net-62.50.0.100 66.100.201.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:23,LUA_SUMMARY:none X-HE-Tag: push29_2ed2400b27226 X-Filterd-Recvd-Size: 5284 Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Sun, 23 Feb 2020 09:32:01 +0000 (UTC) Received: by mail-pg1-f196.google.com with SMTP id 6so3428173pgk.0 for ; Sun, 23 Feb 2020 01:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=M1rhu8g2TsUmdvwz4Fj4mGs/gXjLFCQHg1A5nJXa8n4=; b=sCYEsVwjaXQWZOGQAYk12Tp4pCwyu2Ry27gidyYcAxSoJRC2wVK4xatnBHTYLcKtuH hUshHrf0/XPa8c/rlG9D3Fgpssw//Dqo/v1SGblbPz+gu1LgC1+IZq3Wt5KgxzUqP0tT 5SKp9/iYqh7f2kNut2eMRfUqcUiPEj/1T7QtJ8ozRBfRMxFjWywxAkD9Dw96JtA47b6A hzNU+3jmuWsXg7jdJ3/+NC67oJR0BO4rfs+EMJzLZuXXHOjB3z7CLectM08iihq6NxUL nhrxPDQ+3856mwPw219VQ5Zyzd/OmM7NS2roMoH6aUJ+WmX0YuPJfXVbUiTR4fWohTd3 8N1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=M1rhu8g2TsUmdvwz4Fj4mGs/gXjLFCQHg1A5nJXa8n4=; b=BsYtbncm3yxaQOtx22SAaVlB676nX9RC6QGMTz72FqWBhnqsT1Gx4P++g6u0ilk7eG /RZ433DgPdpbuWMsR7buv0qZqFn7XTqiY1BPrKI1Oweau6Q3tlSnZZo+gxZ4wNegHt12 UDeDzfCRdD4tF6kSqfWDSOS8ZAYd4gy9fu20sa28L6qkV/qXD8enBrr2S4OyB1+fMtrD wRsz541/NExQ5K9lkaNwbxxq0a6aQCmw3Af3PbN1WdMqRsOkHnsQ3bXcNNTv0a855hYt ognJuJMdxWnfHqHulBbkCFF4KycXC76cy88NVeYTKydenLdt322lYDeFNAaEAiG12vLh sJ5A== X-Gm-Message-State: APjAAAWc3mp+PtylAKWvAsol9vXrunFZWHaWVUGw0vcYCIJUgDHS5Ejy 5AyOTPwNlpOMCVFkcOGUGHU= X-Google-Smtp-Source: APXvYqwb2TMNfB6xJBZkGZEK1J6VD05yqRVMM8h02ltxDFdq29cqYdOnwR6sPOLMOu2WCAnM2X3ITQ== X-Received: by 2002:aa7:8bda:: with SMTP id s26mr47260232pfd.194.1582450320516; Sun, 23 Feb 2020 01:32:00 -0800 (PST) Received: from dev.localdomain ([203.100.54.194]) by smtp.gmail.com with ESMTPSA id t19sm8346011pgg.23.2020.02.23.01.31.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2020 01:31:59 -0800 (PST) From: Yafang Shao To: dchinner@redhat.com, hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, guro@fb.com, akpm@linux-foundation.org, viro@zeniv.linux.org.uk Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Yafang Shao Subject: [PATCH v4 0/3] protect page cache from freeing inode Date: Sun, 23 Feb 2020 04:31:31 -0500 Message-Id: <1582450294-18038-1-git-send-email-laoar.shao@gmail.com> X-Mailer: git-send-email 1.8.3.1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 v3: Fix the possible risk pointed by Johannes in another patchset [1]. Per discussion with Johannes in that mail thread, I found that the issue Johannes is trying to fix is different with the issue I'm trying to fix. That's why I update this patchset and post it again. This specific memcg protection issue should be addressed. - Changes against v2: 1. Seperates memcg patches from this patchset, suggested by Roman. 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/20200211175507.178100-1-hannes@cmpxchg.org/ 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 inode: protect page cache from freeing inode fs/inode.c | 76 ++++++++++++++++++++++++++++++++++++++++++++-- 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, 141 insertions(+), 48 deletions(-)