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=-6.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 0B0FEC432BE for ; Mon, 30 Aug 2021 17:26:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3CEAA60ED8 for ; Mon, 30 Aug 2021 17:26:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3CEAA60ED8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=peda.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8FB3A6B0071; Mon, 30 Aug 2021 13:26:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AAB18D0001; Mon, 30 Aug 2021 13:26:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BFE16B0073; Mon, 30 Aug 2021 13:26:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id 6BDAB6B0071 for ; Mon, 30 Aug 2021 13:26:23 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2672D180AD81A for ; Mon, 30 Aug 2021 17:26:23 +0000 (UTC) X-FDA: 78532425846.36.E7E6527 Received: from lb1.peda.net (lb1.peda.net [130.234.6.152]) by imf26.hostedemail.com (Postfix) with ESMTP id 7575F20019D3 for ; Mon, 30 Aug 2021 17:26:22 +0000 (UTC) Received: from [84.251.221.37] (dsl-jklbng12-54fbdd-37.dhcp.inet.fi [84.251.221.37]) by lb1.peda.net (Postfix) with ESMTPSA id 08CFF60001C; Mon, 30 Aug 2021 20:26:20 +0300 (EEST) Subject: Re: Why is Shmem included in Cached in /proc/meminfo? To: Matthew Wilcox , Vlastimil Babka Cc: Randy Dunlap , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <5a42eb2b-fd7b-6296-f5d6-619661ad1418@peda.net> <0d11f620-0562-e150-259d-85de8d10cd7a@infradead.org> <14465cfe-281a-0f67-dc17-ead34ec48365@suse.cz> From: Mikko Rantalainen Message-ID: <0cdd0624-fcc3-386e-c651-7173dc3cbb59@peda.net> Date: Mon, 30 Aug 2021 20:26:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Authentication-Results: imf26.hostedemail.com; dkim=none; spf=none (imf26.hostedemail.com: domain of mikko.rantalainen@peda.net has no SPF policy when checking 130.234.6.152) smtp.mailfrom=mikko.rantalainen@peda.net; dmarc=none X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7575F20019D3 X-Stat-Signature: gzgmkos19ohgketyg5ti1nkrp6fm3fhn X-HE-Tag: 1630344382-548512 Content-Transfer-Encoding: quoted-printable 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: Matthew Wilcox (2021-08-30 19:17 Europe/Helsinki): > On Mon, Aug 30, 2021 at 06:05:58PM +0200, Vlastimil Babka wrote: >> On 8/30/21 16:41, Matthew Wilcox wrote: >>> 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 somethi= ng that >> (if not dirty) can't be just dropped. >=20 > That's equally true for normal filesystems & shmem though. Consider sh= mem > 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. >=20 >> I've had to point this Shmem oddity out a >> number of times to someone, so I would say that it would be much bette= r if it >> was not part of Cached. >> However, if we change it now, we might create even larger confusion. P= eople >> looking at the output for the first time (and IIRC also the 'free' com= mand uses >> it) on a new kernel wouldn't be misled anymore. But people working wit= h both old >> and new kernels will now have to take in account that it changed at so= me >> point... not good. >=20 > Another good point. I agree that backwards compatibility is a huge point to consider. That said, I always assumed that Shmem was in *addition* to Cached and I was happy to see lots of Cached on all my systems. However, when I started to run into OOM situations with 10+ GB of Cached I guessed that something was not working correctly with memory reclaim - it turned out that the problem was that over 95% of my "Cached" was actually Shmem. Do you know any existing software where it's important to have the behavior of Cached and Shmem that the current kernel has? Without backwards compatibility issues I'd prefer following fields: - Dirty: total amount of RAM used to buffer data to be written on permanent storage (dirty). Gets converted to Cached when write is complete. (Actually I would call this "Buffers" but Dirty is okay, too.) - Cached: total amount of RAM used to improve *performance* that can be *immediately dropped* without any data-loss =E2=80=93 note that this incl= udes all untouched RAM backed by swap. - Shared: total amount of RAM shared between multiple process that cannot be freed even if any single process gets killed. (If this is even possible to know - note that this would *only* contain COW pages in practice. We already have Committed_AS which is about as good for real world heuristics.) - RamDrive: total amount of RAM used for tmpfs storage and similar. Note that this would tend towards zero when tmpfs storage is written to swap. - Committed_RamDrive: virtual amount of space used for tmpfs (e.g. large truncated files that, if written, will require to be backed for real). - Swapped_RamDrive: the amount of swap backing tmpfs and similar. - LegacyIPCS: all stuff reported by ipcs. That is, I would declare "Cached" as true cache and split Shmem into separate parts that are easier to understand. The Shmem currently seems to be catch-all class for more and more stuff. Obviously the Shmem field could be kept as precomputed sum of the separate parts for backwards compatibility. Does Shmem nowadays include other big memory users but ipcs and tmpfs? My point is that it's currently too hard to understand (at least) tmpfs and ipcs load on RAM and swap. I guess the important thing to decide is if "Cached" should represent actual cache size or is backwards compatibility more important? My guess is that the backwards compability would affect statistics and heuristics only but that's obviously just a guess. Of course one possible solution is to keep "Cached" as is and introduce "Cache" with the real cache semantics (that is, it includes sum of (Cached - Shmem) and memory backed RAM). That way system administrators would at least see two different fields with unique values and look for the documentation. --=20 Mikko