On 05/24/2018 05:32 PM, Johannes Weiner wrote: > On Thu, May 24, 2018 at 01:00:06PM +0200, Vlastimil Babka wrote: >> - the vmstat/meminfo counter name is rather general and might suggest it also >> includes reclaimable page caches, which it doesn't >> >> Suggestions welcome for all three points. For the last one, we might also keep >> the counter separate from nr_slab_reclaimable, not superset. I did a superset >> as IIRC somebody suggested that in the older threads or at LSF. > > Yeah, the "reclaimable" name is too generic. How about KReclaimable? > > The counter being a superset sounds good to me. We use this info for > both load balancing and manual debugging. For load balancing code it's > nice not having to worry about finding all the counters that hold > reclaimable memory depending on kernel version; it's always simply > user cache + user anon + kernel reclaimable. And for debugging, we can > always add more specific subset counters later on if we need them. Hm, Christoph in his reply to patch 4/5 expressed a different opinion. It's true that updating two counters has extra overhead, especially if there are two separate critical sections: mod_lruvec_page_state(page, NR_SLAB_RECLAIMABLE, nr_pages); mod_node_page_state(page_pgdat(page), NR_RECLAIMABLE, nr_pages); The first disables irq for CONFIG_MEMCG or defers to mod_node_page_state() otherwise. mod_node_page_state() is different depending on CONFIG_SMP and CONFIG_HAVE_CMPXCHG_LOCAL. I don't see an easy way to make this optimal? Different counter would be indeed simpler. /proc/vmstat would then print separate counters, but we could have both separate and summary counter in /proc/meminfo. Would that be enough? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
