From patchwork Tue Dec 24 07:53:21 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 11309153 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 6ACED109A for ; Tue, 24 Dec 2019 07:55:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 372322071E for ; Tue, 24 Dec 2019 07:55:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b2EI3mhw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 372322071E 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 4EDD88E0005; Tue, 24 Dec 2019 02:55:15 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 49D148E0001; Tue, 24 Dec 2019 02:55:15 -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 3B30D8E0005; Tue, 24 Dec 2019 02:55:15 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id 254008E0001 for ; Tue, 24 Dec 2019 02:55:15 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id B5A0D1F1D for ; Tue, 24 Dec 2019 07:55:14 +0000 (UTC) X-FDA: 76299274548.29.end28_10a3245d8b646 X-Spam-Summary: 2,0,0,2b9e7ffd65352c07,d41d8cd98f00b204,laoar.shao@gmail.com,:hannes@cmpxchg.org:david@fromorbit.com:mhocko@kernel.org:vdavydov.dev@gmail.com:akpm@linux-foundation.org:viro@zeniv.linux.org.uk::linux-fsdevel@vger.kernel.org:laoar.shao@gmail.com,RULES_HIT:41:69:355:379:541:965:966:988:989:1260:1345:1437:1534:1542:1711:1730:1747:1777:1792:2196:2199:2393:2553:2559:2562:2693:2897:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:4385:4390:4395:4470:4605:5007:6261:6653:7875:7903:8603:9413:10004:11026:11232:11473:11658:11914:12043:12048:12291:12296:12297:12517:12519:12679:12683:12895:13138:13161:13229:13231:13618:14096:14394:14687:14721:21080:21444:21450:21451:21627:21666:30054:30070:30090,0,RBL:209.85.216.66:@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:none,Custom_rules:0:0:0,LFtime:23,LUA_SUMMARY:none X-HE-Tag: end28_10a3245d8b646 X-Filterd-Recvd-Size: 4720 Received: from mail-pj1-f66.google.com (mail-pj1-f66.google.com [209.85.216.66]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Dec 2019 07:55:14 +0000 (UTC) Received: by mail-pj1-f66.google.com with SMTP id r67so875881pjb.0 for ; Mon, 23 Dec 2019 23:55:14 -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=2+v0d7iT3tOVdHEBeSInAbmod4y43u3/BCaAImk6sv8=; b=b2EI3mhwKNVIOshHL94J215WbXmGgocrzV7SjSDvSMJLs1a7MNc6K5aWnHu849eHMU ecnXUX91PezOVXaMgrkzX6QcsigrU9gn75ZWtPcADxWoGg/t4I2+cU2zkuvpFAA9ZsOD m3krp9CHRQfhb7UBk1uaP5pysi1z0VyG35EFtKzwBVnujfzgLLKTWl3uJxDFhziHrYd2 i3/Ey2nHw4WcUdzHmPYXUvl7WP9posu0a1p5ZGOx/tmw4Vmp50Dj4G2pONucBeh4GLvh 3GT9XuTV89Ba8Xesk+bHQTEPB2skJp7Yl2usbmKR3ZSSGrAiMeaINAR3xk0QqXzrnTi9 7mzQ== 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=2+v0d7iT3tOVdHEBeSInAbmod4y43u3/BCaAImk6sv8=; b=q1xiY/zxc4eOf9ykFjXDJsb5iYVUfSFNRom0LVXbNN1ESWxzW1t0A5UzJCTv3BvEHz Z9W9RrU4UJH8coqKcnXsK/oY6k3/xgCWy1cAHL79rWU1rYMLq/z+T6HgecOzwGavJVQa Fz8/oWdNEDc9XUldj1wINHj7+Dm3TYEsJexxQKKunYSBnlQj6g9whT0pmISYf/PjsZOM BmXeNNqYV9DGG13ufKuebS5Wthrxkiu71tik7XtnUoD9AqMi+dCFhnLvs9IZ9QIRuH1o feZtj5kwxsS805uQB0sZB1WdFiJzOfkgfm3l7D7ic4P//sx14t/0tVk9sPuzV7kLIYKH G4WA== X-Gm-Message-State: APjAAAU9NK+P9SR6IWxlJDIvo3YhbeL61OuRoGgPnwMskhwJjUkEwbPY 7dTr+1t3Va4lvktGiH0Y8iI= X-Google-Smtp-Source: APXvYqxam6oaRmmA0S2FpYpIaLPXtczqcatLHCZltwpvFqrqE8jDqQlqLvMHatuYfR3BaMkkRo7EWA== X-Received: by 2002:a17:902:bf47:: with SMTP id u7mr35584424pls.259.1577174113147; Mon, 23 Dec 2019 23:55:13 -0800 (PST) Received: from dev.localdomain ([203.100.54.194]) by smtp.gmail.com with ESMTPSA id c2sm2004064pjq.27.2019.12.23.23.55.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Dec 2019 23:55:12 -0800 (PST) From: Yafang Shao To: hannes@cmpxchg.org, david@fromorbit.com, mhocko@kernel.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, viro@zeniv.linux.org.uk Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Yafang Shao Subject: [PATCH v2 0/5] protect page cache from freeing inode Date: Tue, 24 Dec 2019 02:53:21 -0500 Message-Id: <1577174006-13025-1-git-send-email-laoar.shao@gmail.com> X-Mailer: git-send-email 1.8.3.1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000764, 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. This patchset contains five patches, Patches 1-3: Minor opmizations and also the preparation of Patch-5 Patch 4: Preparation of Patch-5 Patch 5: the real issue I want to fix - 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. Yafang Shao (5): mm, memcg: reduce size of struct mem_cgroup by using bit field mm, memcg: introduce MEMCG_PROT_SKIP for memcg zero usage case mm, memcg: reset memcg's memory.{min, low} for reclaiming itself mm: make memcg visible to lru walker isolation function memcg, inode: protect page cache from freeing inode fs/inode.c | 25 ++++++++++++++-- include/linux/memcontrol.h | 54 ++++++++++++++++++++++++++++------- mm/list_lru.c | 22 +++++++------- mm/memcontrol.c | 71 +++++++++++++++++++++++++++++++++++----------- mm/vmscan.c | 11 +++++++ 5 files changed, 144 insertions(+), 39 deletions(-)