linux-kernel - Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON

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: <20160713133701.GK9806@techsingularity.net>
Date:	Wed, 13 Jul 2016 14:37:01 +0100
From:	Mel Gorman <mgorman@...hsingularity.net>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>, Rik van Riel <riel@...riel.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Minchan Kim <minchan@...nel.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED

On Wed, Jul 13, 2016 at 09:04:15AM -0400, Johannes Weiner wrote:
> > Obviously I found the new names clearer but I was thinking a lot at the
> > time about mapped vs unmapped due to looking closely at both reclaim and
> > [f|m]advise functions at the time. I found it mildly irksome to switch
> > between the semantics of file/anon when looking at the vmstat updates.
> 
> I can see that. It all depends on whether you consider mapping state
> or page type the more fundamental attribute, and coming from the
> mapping perspective those new names make sense as well.
> 

>From a reclaim perspective, I consider the mapped state to be more
important. This is particularly true when the advise calls are taken
into account. For example, madvise unmaps the pages without affecting
memory residency (distinct from RSS) without aging. fadvise ignores mapped
pages so the mapped state is very important for advise hints.  Similarly,
the mapped state can affect how the pages are aged as mapped pages affect
slab scan rates and incur TLB flushes on unmap. I guess I've been thinking
about mapped/unmapped a lot recently which pushed me towards distinct naming.

> However, that leaves the disconnect between the enum name and what we
> print to userspace. I find myself having to associate those quite a
> lot to find all the sites that modify a given /proc/vmstat item, and
> that's a bit of a pain if the names don't match.
> 

I was tempted to rename userspace what is printed to vmstat as well but
worried about breaking tools that parse it.

> I don't care strongly enough to cause a respin of half the series, and
> it's not your problem that I waited until the last revision went into
> mmots to review and comment. But if you agreed to a revert, would you
> consider tacking on a revert patch at the end of the series?
> 

In this case, I'm going to ask the other people on the cc for a
tie-breaker. If someone else prefers the old names then I'm happy for
your patch to be applied on top with my ack instead of respinning the
whole series.

Anyone for a tie breaker?

-- 
Mel Gorman
SUSE Labs