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 8847BC432BE for ; Mon, 30 Aug 2021 16:18:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 193F460724 for ; Mon, 30 Aug 2021 16:18:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 193F460724 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 A0ADF6B0071; Mon, 30 Aug 2021 12:18:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B9FF8D0001; Mon, 30 Aug 2021 12:18:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 882C56B0073; Mon, 30 Aug 2021 12:18:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 778ED6B0071 for ; Mon, 30 Aug 2021 12:18:32 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2DD6C269D5 for ; Mon, 30 Aug 2021 16:18:32 +0000 (UTC) X-FDA: 78532254864.40.FBADCE2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 90972B000099 for ; Mon, 30 Aug 2021 16:18:31 +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=OyHQehmuanM4OzdDq4FC98poxLZdCC+ppDA2dlDQPmU=; b=Qlk9uaAEQcoBsCdrDO8xYqIIDy QTZA6cFLVPrVGD3bqBbE3e81GJ/Y/M/rZlAGS27AR4Az3amvei8bmrGyY/NCsbFSygcNUD+tBOHEm CXRDW1E9U9uhALvsELQZPTrb2iyW2VEwnZrM1L8WpM36fSLromLVPj7dNgqBhsf7LYXsaCb3GV0ou cXTJ2k4LBTAhjVmZ1GImMSg1KkUqCTq/yFBXzdXCZL14epaE1pT5OudkHnJfK/tz/QwPxSIxEDJjg Ss8bUPevZxg+mLoWgI4yHWthS3Xqjg7SkyH/Z1MzUh+bjZf0sez5grJvoFKnA7hQZ9RjbPColMLM4 NQt64ImQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKjyl-000JiA-Mt; Mon, 30 Aug 2021 16:17:52 +0000 Date: Mon, 30 Aug 2021 17:17:47 +0100 From: Matthew Wilcox To: Vlastimil Babka Cc: Randy Dunlap , 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> <14465cfe-281a-0f67-dc17-ead34ec48365@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14465cfe-281a-0f67-dc17-ead34ec48365@suse.cz> Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Qlk9uaAE; dmarc=none; spf=none (imf24.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: 90972B000099 X-Stat-Signature: 9nq4fp1jass6r71xodqz5tkxsh3cnymu X-HE-Tag: 1630340311-599688 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 06:05:58PM +0200, Vlastimil Babka wrote: > On 8/30/21 16:41, Matthew Wilcox wrote: > > 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. > > Yeah, but with that view, anonymous memory can be also written out to swap. But > it's non-intuitive that something called "Cached" will contain something that > (if not dirty) can't be just dropped. That's equally true for normal filesystems & shmem though. Consider shmem written to swap, then brought back in by a read. Now it can be dropped without being swapped out. Or even a file on shmem ftruncated to a large size, then only read. The pages will be clean and full of zeroes. They can be dropped under memory pressure without being written out. > I've had to point this Shmem oddity out a > number of times to someone, so I would say that it would be much better if it > was not part of Cached. > However, if we change it now, we might create even larger confusion. People > looking at the output for the first time (and IIRC also the 'free' command uses > it) on a new kernel wouldn't be misled anymore. But people working with both old > and new kernels will now have to take in account that it changed at some > point... not good. Another good point.