linux-kernel - Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

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] [day] [month] [year] [list]

Message-ID: <CALYGNiPzZ=GtKn1v0NQZhRu=Ns6P5SVNOaeMPT17XK=T4n5F0w@mail.gmail.com>
Date:	Mon, 29 Feb 2016 10:03:25 +0300
From:	Konstantin Khlebnikov <koct9i@...il.com>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kernel-team@...com
Subject: Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Mon, Feb 29, 2016 at 3:03 AM, Hugh Dickins <hughd@...gle.com> wrote:
> On Fri, 19 Feb 2016, Andrew Morton wrote:
>> On Fri, 19 Feb 2016 09:40:45 +0300 Konstantin Khlebnikov <koct9i@...il.com> wrote:
>>
>> > >> What are your thoughts on this?
>> > >
>> > > My thoughts are NAK.  A misleading stat is not so bad as a
>> > > misleading stat whose meaning we change in some random kernel.
>> > >
>> > > By all means improve Documentation/filesystems/proc.txt on Cached.
>> > > By all means promote Active(file)+Inactive(file)-Buffers as often a
>> > > better measure (though Buffers itself is obscure to me - is it intended
>> > > usually to approximate resident FS metadata?).  By all means work on
>> > > /proc/meminfo-v2 (though that may entail dispiritingly long discussions).
>> > >
>> > > We have to assume that Cached has been useful to some people, and that
>> > > they've learnt to subtract Shmem from it, if slow or no swap concerns them.
>> > >
>> > > Added Konstantin to Cc: he's had valuable experience of people learning
>> > > to adapt to the numbers that we put out.
>> > >
>> >
>> > I think everything will ok. Subtraction of shmem isn't widespread practice,
>> > more like secret knowledge. This wasn't documented and people who use
>> > this should be aware that this might stop working at any time. So, ACK.
>>
>> It worries me as well - we're deliberately altering the behaviour of
>> existing userspace code.  Not all of those alterations will be welcome!
>>
>> We could add a shiny new field into meminfo and train people to migrate
>> to that.  But that would just be a sum of already-available fields.  In
>> an ideal world we could solve all of this with documentation and
>> cluebatting (and some apologizing!).
>
> Ah, I missed this, and just sent a redundant addition to the thread;
> followed by this doubly redundant addition.

"Cached" has been used for ages as amount of "potentially free memory".
This patch corrects it in original meaning and makes it closer to that
"potential"
meaining at the same time.

MemAvailable means exactly that and thing else so logic behind it could be
tuned and changed in the future. Thus, adding new fields makes no sense.


BTW
Glibc recently switched sysconf(_SC_PHYS_PAGES) / sysconf(_SC_AVPHYS_PAGES)
from /proc/meminfo MemTotal / MemFree to sysinfo(2) totalram / freeram for
performance reason. It seems possible to expose MemAvailable via sysinfo:
there is space for one field. Probably it's also possible to switch
_SC_AVPHYS_PAGES
to really available memory and add memcg awareness too.