Re: [LSF/MM TOPIC] memory control groups

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2011-01-18 17:45:23]:

> On Tue, 18 Jan 2011 00:17:53 -0800
> Michel Lespinasse <walken@google.com> wrote:
> 
> 
> > > The per-memcg dirty accounting work e.g. allocates a bunch of new bits
> > > in pc->flags and I'd like to hash out if this leaves enough room for
> > > the structure packing I described, or whether we can come up with a
> > > different way of tracking state.
> > 
> > This is probably longer term, but I would love to get rid of the
> > duplication between global LRU and per-cgroup LRU. Global LRU could be
> > approximated by scanning all per-cgroup LRU lists (in mounts
> > proportional to the list lengths).
> > 
> 
> I can't answer why the design, which memory cgroup's meta-page has its own LRU
> rather than reusing page->lru, is selected at 1st implementation because I didn't
> join the birth of memcg. Does anyone remember the reason or discussion ? 
>

The discussions can be found on LKML, some happened during OLS.
Keeping local LRU and global LRU was very important because we wanted
to make sure global reclaim is not broken or affected. We can discuss
this further.
 

-- 
	Three Cheers,
	Balbir

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>