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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 813B7C4BA10 for ; Wed, 26 Feb 2020 14:16:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 469DB24685 for ; Wed, 26 Feb 2020 14:16:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="vTrIHT4m" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 469DB24685 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 EB7BA6B0003; Wed, 26 Feb 2020 09:16:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E67986B0005; Wed, 26 Feb 2020 09:16:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA46D6B0006; Wed, 26 Feb 2020 09:16:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id C3DB36B0003 for ; Wed, 26 Feb 2020 09:16:54 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8E7D1824556B for ; Wed, 26 Feb 2020 14:16:54 +0000 (UTC) X-FDA: 76532479548.04.spade24_595f701b5d919 X-HE-Tag: spade24_595f701b5d919 X-Filterd-Recvd-Size: 5380 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Feb 2020 14:16:54 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id x7so374599ilq.11 for ; Wed, 26 Feb 2020 06:16:53 -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=zKkmJsF9Hl657kgJGnJj+omKg/OfeYPnAzsoJ5sWtno=; b=vTrIHT4mP9ERZDSFPzK1ncQQDAj2Xv89LD56xygEoWafU31IHdaH/QBgaQDyjhMW0G Pr4xH8ErQcv1GxysuCdxxXz1WthNQyngsUjGHsDvMH3wF8cIWMZrl/oEUfBc/Xw7NInT eMju7GvzUQvV3deDDQe7gTau4PgloeyfQ2vrjMvbj6+G3lQh2TxxcFtW17h2YRgHi/Bi 9huZoLX9/ipMHDQAspjWNZuLiDr6yz0Z1Bg+qVB4A7087VXw7iM9t4LWmV37Lu4A9pLq GjQQ5fd2h5ECVEJFw87datIQY87TOZjBE6y2kFllQflUb9BRJrVbK2DK34v641tBoiYw 0tmg== 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=zKkmJsF9Hl657kgJGnJj+omKg/OfeYPnAzsoJ5sWtno=; b=VXkaMZnYLCYSb7IEz572bJDHO3SaWeoRmMPbEcPPqSYVjurlxSOOLdar8LhgxISqWh oQek5ZxLK5k5edJOln09S+BbksNp7bV7YIox8DwSxOy46ICrp6ig09f+plYsqOnczTKi 5BCE9na4RTszn1MdQTWFAELXaBPoBDpSBCXuYJZzQoe5ci/nQ2eMhXxlmDdTP4ydQK0M 0PusW97R32IIDLIkNKvRYbSvNFXE7daR/KtwqTjj+vF52UAktNJ5ai8rI1xU77WVuL6m NBS4sBRunn6T3VazqvM5tSakxYxyd+OPZWGk3dRt3u3HLpmJ6R0LMKpSs2dngYapy/Lp cj6w== X-Gm-Message-State: APjAAAXsZ6M/LIhRiNRTcdUf87Xbcp5ZjrvaW+67mY0NpnZYfyuLfDnU nEj4clxLK9ixjPdLwKQfKSBtxJzl2D3Jo8OdqQN0+fdD X-Google-Smtp-Source: APXvYqx455mYmZxNyLsIHHpy8E8XyXo+Di+V1pd6m1CK+p1jG77rykVphYYvILwwPZXRovho2sPh84OYxW2xiXQ3nJ8= X-Received: by 2002:a92:84ce:: with SMTP id y75mr5055650ilk.93.1582726613296; Wed, 26 Feb 2020 06:16:53 -0800 (PST) MIME-Version: 1.0 References: <1582450294-18038-1-git-send-email-laoar.shao@gmail.com> <20200223191707.0a55e949fad943b04c2b65e7@linux-foundation.org> In-Reply-To: <20200223191707.0a55e949fad943b04c2b65e7@linux-foundation.org> From: Yafang Shao Date: Wed, 26 Feb 2020 22:16:17 +0800 Message-ID: Subject: Re: [PATCH v4 0/3] protect page cache from freeing inode To: Andrew Morton Cc: Dave Chinner , Johannes Weiner , Michal Hocko , Vladimir Davydov , Roman Gushchin , 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 Mon, Feb 24, 2020 at 11:17 AM Andrew Morton wrote: > > 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? > Sorry about the late response. Yes, lots of inodes pinned by small amounts of pagecache in a memcg protected by memory.{min, low} could be a potential regression scenarios. It may take extra time to skip these inodes when a workload outside of these memcg is trying to do page reclaim. But these extra time can almostly be ignored comparing with the time the memory.{min, low} may take, because memory.{min, low} takes another round to scan all the pages again. While if the workload trying to reclaim these protected inodes is inside of the protected memcg, then this workload will not be effected at all because memory.{min, low} doesn't take effect under these condition. > Have you considered constructing test cases to evaluate the impact of > such things? > I did some mmtests::pagereclaim-performance test with lots of protected inodes pinned by small amounts of pagecache. The result doesn't show any obvious difference with this patchset. I will update it with these test data. Appreciate it if you could recommend some better tests tools. -- Yafang Shao DiDi