linux-kernel - Re: Why is Shmem included in Cached in /proc/meminfo?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Aug 2021 17:17:47 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Mikko Rantalainen <mikko.rantalainen@...a.net>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: Why is Shmem included in Cached in /proc/meminfo?

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.