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:   Fri, 21 Oct 2016 09:36:49 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Johannes Weiner <hannes@...xchg.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Hugh Dickins <hughd@...gle.com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: [RFC] fs/proc/meminfo: introduce Unaccounted statistic

On Fri 21-10-16 09:59:29, Dave Chinner wrote:
> On Thu, Oct 20, 2016 at 03:33:58PM +0200, Michal Hocko wrote:
> > On Thu 20-10-16 14:11:49, Vlastimil Babka wrote:
> > [...]
> > > Hi, I'm wondering if people would find this useful. If you think it is, and
> > > to not make performance worse, I could also make sure in proper submission
> > > that values are not read via global_page_state() multiple times etc...
> > 
> > I definitely find this information useful and hate to do the math all
> > the time but on the other hand this is quite fragile and I can imagine
> > we can easily forget to add something there and provide a misleading
> > information to the userspace. So I would be worried with a long term
> > maintainability of this.
> 
> This will result in valid memory usage by subsystems like the XFS
> buffer cache being reported as "unaccounted".

I would argue that the file is more intended for developers than regular
users. Most of those counters simply require a deep knowledge of the MM
subsystem to interpret them correctly (yeah we have seen many reports
that the free memory is too low but we always managed to explain...).

So to me this is more a convenience thing for developers than anything
else. But my worry about maintainability still stands. People who are
adding new counters might easily forget to update this part, so I am not
actually sure it is a good idea long term. Getting a misleading data is
worse than pushing developers to do the math and scratch their heads
about what should be included IMHO.
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ