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]

Message-ID: <4556646fd511050f41b517173d85888e3bd7cef3.camel@oracle.com>
Date:   Mon, 30 Aug 2021 13:38:29 -0600
From:   Khalid Aziz <khalid.aziz@...cle.com>
To:     Mikko Rantalainen <mikko.rantalainen@...a.net>,
        Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>
Cc:     Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: Why is Shmem included in Cached in /proc/meminfo?

On Mon, 2021-08-30 at 20:26 +0300, Mikko Rantalainen wrote:
> ... deleted ...
> 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.
> 

I would recommend adding new field. There is likely to be a good number
of tools/scripts out there that already interpret the data from
/proc/meminfo and possily take actions based upon that data. Those
tools will break if we change the sense of existing data. A new field
has the down side of expanding the output further but it also doesn't
break existing tols.

--
Khalid