Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1442983

Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED

Show all headers | View raw

On Wed, Jul 13, 2016 at 02:37:01PM +0100, Mel Gorman wrote:
> 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?

I have thought it from reclaim perspective for a long time so I tempted to
change the naming like new one but there is no big justification for that.
In this chance, I vote new name.

Thanks.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Johannes Weiner <hannes@cmpxchg.org> - 2016-07-12 17:00 +0200
  Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Mel Gorman <mgorman@techsingularity.net> - 2016-07-13 11:00 +0200
    Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Johannes Weiner <hannes@cmpxchg.org> - 2016-07-13 15:10 +0200
      Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Mel Gorman <mgorman@techsingularity.net> - 2016-07-13 15:50 +0200
        Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Andrew Morton <akpm@linux-foundation.org> - 2016-07-13 23:20 +0200
          Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Mel Gorman <mgorman@techsingularity.net> - 2016-07-15 12:50 +0200
            Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Andrew Morton <akpm@linux-foundation.org> - 2016-07-16 00:40 +0200
              Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Johannes Weiner <hannes@cmpxchg.org> - 2016-07-18 15:40 +0200
        Re: [PATCH 18/34] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Minchan Kim <minchan@kernel.org> - 2016-07-14 03:30 +0200

csiph-web