[Devel] Re: [PATCH 07/10] memcg: add dirty limits to mem_cgroup
KAMEZAWA Hiroyuki
kamezawa.hiroyu at jp.fujitsu.com
Tue Oct 12 01:38:49 PDT 2010
On Tue, 12 Oct 2010 00:32:33 -0700
Greg Thelen <gthelen at google.com> wrote:
> KAMEZAWA Hiroyuki <kamezawa.hiroyu at 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
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list