Re: [PATCH 07/10] memcg: add dirty limits to mem_cgroup

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Tue, 12 Oct 2010 00:32:33 -0700
Greg Thelen <gthelen@google.com> wrote:

> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:

> >> What are the cases where current->mm->owner->cgroups !=
> >> current->cgroups?
> >> 
> > In that case, assume group A and B.
> >
> >    thread(1) -> belongs to cgroup A  (thread(1) is mm->owner)
> >    thread(2) -> belongs to cgroup B
> > and
> >    a page    -> charnged to cgroup A
> >
> > Then, thread(2) make the page dirty which is under cgroup A.
> >
> > In this case, if page's dirty_pages accounting is added to cgroup B,
> > cgroup B' statistics may show "dirty_pages > all_lru_pages". This is
> > bug.
> 
> I agree that in this case the dirty_pages accounting should be added to
> cgroup A because that is where the page was charged.  This will happen
> because pc->mem_cgroup was set to A when the page was charged.  The
> mark-page-dirty code will check pc->mem_cgroup to determine which cgroup
> to add the dirty page to.
> 
> I think that the current vs current->mm->owner decision is in areas of
> the code that is used to query the dirty limits.  These routines do not
> use this data to determine which cgroup to charge for dirty pages.  The
> usage of either mem_cgroup_from_task(current->mm->owner) or
> mem_cgroup_from_task(current) in mem_cgroup_has_dirty_limit() does not
> determine which cgroup is added for dirty_pages.
> mem_cgroup_has_dirty_limit() is only used to determine if the process
> has a dirty limit.  As discussed, this is a momentary answer that may be
> wrong by the time decisions are made because the task may be migrated
> in-to/out-of root cgroup while mem_cgroup_has_dirty_limit() runs.  If
> the process has a dirty limit, then the process's memcg is used to
> compute dirty limits.  Using your example, I assume that thread(1) and
> thread(2) will git dirty limits from cgroup(A) and cgroup(B)
> respectively.
> 

Ok, thank you for clarification. Throttoling a thread based on its own
cgroup not based on mm->owner makes sense. Could you add a brief comment on
the code ?

Thanks,
-Kame

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>