[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YS0Eq+tNe4Pr7O0X@casper.infradead.org>
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.
Powered by blists - more mailing lists