Re: [PATCH 3/4] memcg: hierarchical reclaim by CSS ID

From: KAMEZAWA Hiroyuki
Date: Thu Jan 15 2009 - 20:59:53 EST


On Fri, 16 Jan 2009 09:49:05 +0800
Li Zefan <lizf@xxxxxxxxxxxxxx> wrote:

> KAMEZAWA Hiroyuki wrote:
> > On Fri, 16 Jan 2009 09:29:48 +0800
> > Li Zefan <lizf@xxxxxxxxxxxxxx> wrote:
> >
> >>> /*
> >>> - * Dance down the hierarchy if needed to reclaim memory. We remember the
> >>> - * last child we reclaimed from, so that we don't end up penalizing
> >>> - * one child extensively based on its position in the children list.
> >>> + * Visit the first child (need not be the first child as per the ordering
> >>> + * of the cgroup list, since we track last_scanned_child) of @mem and use
> >>> + * that to reclaim free pages from.
> >>> + */
> >>> +static struct mem_cgroup *
> >>> +mem_cgroup_select_victim(struct mem_cgroup *root_mem)
> >>> +{
> >>> + struct mem_cgroup *ret = NULL;
> >>> + struct cgroup_subsys_state *css;
> >>> + int nextid, found;
> >>> +
> >>> + if (!root_mem->use_hierarchy) {
> >>> + spin_lock(&root_mem->reclaim_param_lock);
> >>> + root_mem->scan_age++;
> >>> + spin_unlock(&root_mem->reclaim_param_lock);
> >>> + css_get(&root_mem->css);
> >>> + ret = root_mem;
> >>> + }
> >>> +
> >>> + while (!ret) {
> >>> + rcu_read_lock();
> >>> + nextid = root_mem->last_scanned_child + 1;
> >>> + css = css_get_next(&mem_cgroup_subsys, nextid, &root_mem->css,
> >>> + &found);
> >>> + if (css && css_is_populated(css) && css_tryget(css))
> >> I don't see why you need to check css_is_populated(css) ?
> >>
> >
> > Main reason is for sanity. I don't like to hold css->refcnt of not populated css.
>
> I think this is a rare case. It's just a very short period when a cgroup is
> being created but not yet fully created.
>
I don't think so. When the cgroup is mounted with several subsystems, it can call
create() and populate() several times. So, memory allocation occurs between
create() and populate(), it can call try_to_free_page() (of global LRU). More than
that, if CONFIG_PREEMPT=y, any "short" race doesn't mean safe.



Thanks,
-Kame


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/