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
