linux-kernel - Re: [PATCH 07/10] memcg: add dirty limits to mem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Oct 2010 17:38:49 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Greg Thelen <gthelen@...gle.com>
Cc:	Andrea Righi <arighi@...eler.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	containers@...ts.osdl.org,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Daisuke Nishimura <nishimura@....nes.nec.co.jp>
Subject: Re: [PATCH 07/10] memcg: add dirty limits to mem_cgroup

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

> KAMEZAWA Hiroyuki <kamezawa.hiroyu@...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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/