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=-8.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 98DD6C432BE for ; Mon, 30 Aug 2021 16:06:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3EA7B60ED8 for ; Mon, 30 Aug 2021 16:06:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3EA7B60ED8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B78DB6B0071; Mon, 30 Aug 2021 12:06:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B28BD6B0072; Mon, 30 Aug 2021 12:06:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C9806B0073; Mon, 30 Aug 2021 12:06:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0193.hostedemail.com [216.40.44.193]) by kanga.kvack.org (Postfix) with ESMTP id 8DE926B0071 for ; Mon, 30 Aug 2021 12:06:01 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 431EE248B1 for ; Mon, 30 Aug 2021 16:06:01 +0000 (UTC) X-FDA: 78532223322.09.035C4E6 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf13.hostedemail.com (Postfix) with ESMTP id CB2D01021619 for ; Mon, 30 Aug 2021 16:06:00 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 515932216A; Mon, 30 Aug 2021 16:05:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1630339559; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tu3Srlltk1gV5LbtaloNcu/X6jYrN+dgxGU84IwMz4c=; b=GcSn84ueH7DhSedmu/bpQNLBeXS8cpP708lcjMgHPysKF3NXqElrwIwTNYq0khdQ/zppdf oaQeaSLpTD6xYa7zMRF6WiNS8vWFL6Ra0+2rwotd50HnOEQA+44xWVX1ZXIXMeIXnZLbbf eraaWUMTMaxyi4n53gDdsyc2n5pFqdU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1630339559; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tu3Srlltk1gV5LbtaloNcu/X6jYrN+dgxGU84IwMz4c=; b=R+HiVBAoG6mHGxpUhn0rvdNpoCiJfaDoNhy8sJC4EaHIDbo9Y+zgbYRhi4f3uF1HYiXFnF NomOcawYrO+wbwCg== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 336B0139BB; Mon, 30 Aug 2021 16:05:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id cFJYC+cBLWFGHwAAGKfGzw (envelope-from ); Mon, 30 Aug 2021 16:05:59 +0000 Message-ID: <14465cfe-281a-0f67-dc17-ead34ec48365@suse.cz> Date: Mon, 30 Aug 2021 18:05:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0.2 Content-Language: en-US To: Matthew Wilcox , Randy Dunlap Cc: Mikko Rantalainen , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <5a42eb2b-fd7b-6296-f5d6-619661ad1418@peda.net> <0d11f620-0562-e150-259d-85de8d10cd7a@infradead.org> From: Vlastimil Babka Subject: Re: Why is Shmem included in Cached in /proc/meminfo? In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CB2D01021619 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=GcSn84ue; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=R+HiVBAo; dmarc=none; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Rspamd-Server: rspam01 X-Stat-Signature: 6dn6de9cyqwefb4kqgjy7s8ry8s33nem X-HE-Tag: 1630339560-848101 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 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. 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. > 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. >