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

[Matthew Wilcox <willy@infradead.org>]

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.