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
| ||
|
Date: Fri, 12 Oct 2012 11:47:17 +0400 From: Glauber Costa <glommer@...allels.com> To: Michal Hocko <mhocko@...e.cz> CC: <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org>, Mel Gorman <mgorman@...e.de>, Suleiman Souhlal <suleiman@...gle.com>, Tejun Heo <tj@...nel.org>, <cgroups@...r.kernel.org>, <kamezawa.hiroyu@...fujitsu.com>, Johannes Weiner <hannes@...xchg.org>, Greg Thelen <gthelen@...gle.com>, <devel@...nvz.org>, Frederic Weisbecker <fweisbec@...il.com>, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...helsinki.fi> Subject: Re: [PATCH v4 09/14] memcg: kmem accounting lifecycle management On 10/11/2012 05:11 PM, Michal Hocko wrote: > On Mon 08-10-12 14:06:15, Glauber Costa wrote: >> Because kmem charges can outlive the cgroup, we need to make sure that >> we won't free the memcg structure while charges are still in flight. >> For reviewing simplicity, the charge functions will issue >> mem_cgroup_get() at every charge, and mem_cgroup_put() at every >> uncharge. >> >> This can get expensive, however, and we can do better. mem_cgroup_get() >> only really needs to be issued once: when the first limit is set. In the >> same spirit, we only need to issue mem_cgroup_put() when the last charge >> is gone. >> >> We'll need an extra bit in kmem_accounted for that: KMEM_ACCOUNTED_DEAD. >> it will be set when the cgroup dies, if there are charges in the group. >> If there aren't, we can proceed right away. >> >> Our uncharge function will have to test that bit every time the charges >> drop to 0. Because that is not the likely output of >> res_counter_uncharge, this should not impose a big hit on us: it is >> certainly much better than a reference count decrease at every >> operation. >> >> [ v3: merged all lifecycle related patches in one ] >> >> Signed-off-by: Glauber Costa <glommer@...allels.com> >> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com> >> CC: Christoph Lameter <cl@...ux.com> >> CC: Pekka Enberg <penberg@...helsinki.fi> >> CC: Michal Hocko <mhocko@...e.cz> >> CC: Johannes Weiner <hannes@...xchg.org> >> CC: Suleiman Souhlal <suleiman@...gle.com> > > OK, I like the optimization. I have just one comment to the > memcg_kmem_dead naming but other than that > > Acked-by: Michal Hocko <mhocko@...e.cz> > > [...] >> +static bool memcg_kmem_dead(struct mem_cgroup *memcg) > > The name is tricky because it doesn't tell you that it clears the flag > which made me scratch my head when reading comment in kmem_cgroup_destroy > memcg_kmem_finally_kill_that_bastard() ? -- 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/
Powered by blists - more mailing lists