On Thu, 5 Jan 2012, KAMEZAWA Hiroyuki wrote: > On Sat, 31 Dec 2011 23:30:38 -0800 (PST) > Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > > I never understood why we need a MEM_CGROUP_ZSTAT(mz, idx) macro > > to obscure the LRU counts. For easier searching? So call it > > lru_size rather than bare count (lru_length sounds better, but > > would be wrong, since each huge page raises lru_size hugely). > > > > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> > > > Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> Thanks (to you and the other guys) for all the acks. > > BTW, can this counter be moved to lruvec finally ? Well. It could be, but I haven't moved it (even in coming patches), and it's not yet quite clear to me whether that's right or not. Because there's a struct lruvec in struct zone, which we use when !CONFIG_CGROUP_MEM_RES_CTLR or when mem_cgroup_disabled(); but the corresponding lru_sizes would be a waste in those cases, because they then just duplicate vm_stat[NR_INACTIVE_ANON..NR_UNEVICTABLE]. And we want to keep vm_stat[NR_INACTIVE_ANON..NR_UNEVICTABLE], because we do want those global LRU sizes even in the memcg case. Of course, we could put unused lru_size fields in anyway, it would not waste much space. But I'd prefer to hold off for now: I imagine that we're moving towards a future in which even !CONFIG_CGROUP_MEM_RES_CTLR will have a root_mem_cgroup, and it will become clearer what to place where then. We use the lruvec heavily in the per-memcg per-zone locking patches, as something low-level code can operate on without needing to know if it's memcg or global; but have not actually needed to move the lru_sizes into the structure (perhaps it's a hack: there is one place I use container_of to go from the lruvec pointer to the lru_sizes). (I might want to move the reclaim_stat into the lruvec, don't know yet: I only just noticed that there are places where I'm not locking the reclaim_stat properly: it's not such a big deal that it was ever obvious, but I ought to get it right.) Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>