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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 6FC87C35679 for ; Mon, 24 Feb 2020 03:17:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 30927206E0 for ; Mon, 24 Feb 2020 03:17:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="UoIyYySn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 30927206E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B35106B0010; Sun, 23 Feb 2020 22:17:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE6596B0032; Sun, 23 Feb 2020 22:17:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FB4F6B0036; Sun, 23 Feb 2020 22:17:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 840616B0010 for ; Sun, 23 Feb 2020 22:17:10 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 483D9181AC9B6 for ; Mon, 24 Feb 2020 03:17:10 +0000 (UTC) X-FDA: 76523559420.08.bikes93_2176331028c5e X-HE-Tag: bikes93_2176331028c5e X-Filterd-Recvd-Size: 2979 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Feb 2020 03:17:09 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 864B020675; Mon, 24 Feb 2020 03:17:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582514228; bh=/HxwppNKkT1kyDN3qXhCwbz67TGUKxsrBHQM6eDoJk0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UoIyYySn7Rec2UDqle2YDg0gtssCXAt3WBCCuhnl24f9XJmlokz+crC+px95GWpeu Blnloqz8a2P7JZpyjDaT/ybJDmdajW5h1bx21xhlWL6nX/s0emeYCazGoc0WZ9DTzt d/wB0Xqdc4a1BmFhcvfCQB6zVzVdFXVT4EMq7KZo= Date: Sun, 23 Feb 2020 19:17:07 -0800 From: Andrew Morton To: Yafang Shao Cc: dchinner@redhat.com, hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, guro@fb.com, viro@zeniv.linux.org.uk, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 0/3] protect page cache from freeing inode Message-Id: <20200223191707.0a55e949fad943b04c2b65e7@linux-foundation.org> In-Reply-To: <1582450294-18038-1-git-send-email-laoar.shao@gmail.com> References: <1582450294-18038-1-git-send-email-laoar.shao@gmail.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000349, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, 23 Feb 2020 04:31:31 -0500 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. What are the potential regression scenarios here? Presumably a large number of inodes pinned by small amounts of pagecache, consuming memory and CPU during list scanning. Anything else? Have you considered constructing test cases to evaluate the impact of such things?