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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 87329C432BE for ; Mon, 30 Aug 2021 14:42:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1B3096023E for ; Mon, 30 Aug 2021 14:42:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1B3096023E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9ABCB8D0001; Mon, 30 Aug 2021 10:42:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95B4C6B0072; Mon, 30 Aug 2021 10:42:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84A6E8D0001; Mon, 30 Aug 2021 10:42:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id 761C76B0071 for ; Mon, 30 Aug 2021 10:42:16 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1BA01180B2636 for ; Mon, 30 Aug 2021 14:42:16 +0000 (UTC) X-FDA: 78532012272.03.5CB5832 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id E2C636001984 for ; Mon, 30 Aug 2021 14:42:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=EZA4oxuCnUaen/bj4k8tdkq2jibgifMiILkBMqfWID0=; b=tyx99hhd0HIIPh8tn7k1fWYyLz 1790ARWjQCLnsX1HowT/oGgasjvtR91zrZKFVXrg5XElgmIKyOhRzf+t1PDvF5cmsp94He91DRPEQ YgvFNRZPiybebXKXQtVs6ofG0aLAEf6JM39vjgaOCWwLJmOSz46v0zvv2K3c64DzB2TiUahTlNUZQ 8niY5SFpHmxIkc4YNJXUl6O1PkrZvGArOgK05bgbIP+4r9xa9GF0MH1IlHOphl+gLVuE5F61/fhmF TPvPnIxwy6pMLDmRLD6WJXCUKjjA6vcRycu9njcUkqkfIcmP1k3LWeN/Q9p9xmFiJBCGFbmZiCemV xqjOE1Pw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKiTt-000FAi-4s; Mon, 30 Aug 2021 14:41:55 +0000 Date: Mon, 30 Aug 2021 15:41:49 +0100 From: Matthew Wilcox To: Randy Dunlap Cc: Mikko Rantalainen , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: Why is Shmem included in Cached in /proc/meminfo? Message-ID: References: <5a42eb2b-fd7b-6296-f5d6-619661ad1418@peda.net> <0d11f620-0562-e150-259d-85de8d10cd7a@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0d11f620-0562-e150-259d-85de8d10cd7a@infradead.org> Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tyx99hhd; dmarc=none; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E2C636001984 X-Stat-Signature: h6zgfj3p9zxck7hr5eymn8r5sgfrhewf X-HE-Tag: 1630334535-636995 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, Aug 30, 2021 at 07:34:38AM -0700, Randy Dunlap wrote: > [add linux-mm mailing list] > > On 8/30/21 12:44 AM, Mikko Rantalainen wrote: > > It's not immediately obvious from fs/proc/meminfo.c function > > meminfo_proc_show() but the output of Cached: field seems to always > > include all of Shmem: field, too. > > > > Is this intentional? Usually cache is something that can be discarded if > > needed but shared memory (e.g. used to contain files in tmpfs) cannot be > > discarded without a data-loss. As such, I'd argue that it shouldn't be > > included in the Cached: output. That's a reasonable position to take. Another point of view is that everything in tmpfs is part of the page cache and can be written out to swap, so keeping it as part of Cached is not misleading. I can see it both ways, and personally, I'd lean towards clarifying the documentation about how shmem is accounted rather than changing how the memory usage is reported.