* [PATCH v6 0/5] memcg, cgroup: kill css id
@ 2013-09-23 8:55 Li Zefan
2013-09-23 8:55 ` [PATCH v6 1/5] memcg: convert to use cgroup_is_descendant() Li Zefan
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Li Zefan @ 2013-09-23 8:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Tejun Heo, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML,
cgroups, linux-mm@kvack.org
Hi Andrew,
The whole patchset has been acked and reviewed by Michal and Tejun.
Could you merge it into mm tree?
===========
This patchset converts memcg to use cgroup->id, and then we remove cgroup
css_id.
As we've removed memcg's own refcnt, converting memcg to use cgroup->id
is very straight-forward.
v6:
- rebased against mmotm 2013-09-20-15-59
- moved cgroup id check from mem_cgroup_css_alloc() to mem_cgroup_css_online()
v5:
- rebased against mmotm 2013-08-07-16-55
v4:
- make cgroup_from_id() inline and check if cgroup_mutex is held.
- add a comment for idr_remove() in cgroup_offline)fn().
v2->v3:
- some minor cleanups suggested by Michal.
- fixed the call to idr_alloc() in cgroup_init() in the first patch.
Li Zefan (5):
memcg: convert to use cgroup_is_descendant()
memcg: convert to use cgroup id
memcg: fail to create cgroup if the cgroup id is too big
memcg: stop using css id
cgroup: kill css_id
include/linux/cgroup.h | 37 --------
kernel/cgroup.c | 248 +------------------------------------------------
mm/memcontrol.c | 66 +++++++------
3 files changed, 41 insertions(+), 310 deletions(-)
--
1.8.0.2
--
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>
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH v6 1/5] memcg: convert to use cgroup_is_descendant() 2013-09-23 8:55 [PATCH v6 0/5] memcg, cgroup: kill css id Li Zefan @ 2013-09-23 8:55 ` Li Zefan 2013-09-23 8:56 ` [PATCH v6 2/5] memcg: convert to use cgroup id Li Zefan ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Li Zefan @ 2013-09-23 8:55 UTC (permalink / raw) To: Andrew Morton Cc: Tejun Heo, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm@kvack.org This is a preparation to kill css_id. Signed-off-by: Li Zefan <lizefan@huawei.com> Acked-by: Michal Hocko <mhocko@suse.cz> --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7dda769..9117249 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1405,7 +1405,7 @@ bool __mem_cgroup_same_or_subtree(const struct mem_cgroup *root_memcg, return true; if (!root_memcg->use_hierarchy || !memcg) return false; - return css_is_ancestor(&memcg->css, &root_memcg->css); + return cgroup_is_descendant(memcg->css.cgroup, root_memcg->css.cgroup); } static bool mem_cgroup_same_or_subtree(const struct mem_cgroup *root_memcg, -- 1.8.0.2 -- 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> ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v6 2/5] memcg: convert to use cgroup id 2013-09-23 8:55 [PATCH v6 0/5] memcg, cgroup: kill css id Li Zefan 2013-09-23 8:55 ` [PATCH v6 1/5] memcg: convert to use cgroup_is_descendant() Li Zefan @ 2013-09-23 8:56 ` Li Zefan [not found] ` <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 2013-09-24 1:46 ` Tejun Heo 3 siblings, 0 replies; 14+ messages in thread From: Li Zefan @ 2013-09-23 8:56 UTC (permalink / raw) To: Andrew Morton Cc: Tejun Heo, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm@kvack.org Use cgroup id instead of css id. This is a preparation to kill css id. Note, as memcg treat 0 as an invalid id, while cgroup id starts with 0, we define memcg_id == cgroup_id + 1. Signed-off-by: Li Zefan <lizefan@huawei.com> Acked-by: Michal Hocko <mhocko@suse.cz> --- mm/memcontrol.c | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 9117249..6719e2c 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -498,6 +498,23 @@ static inline bool mem_cgroup_is_root(struct mem_cgroup *memcg) return (memcg == root_mem_cgroup); } +static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg) +{ + /* + * The ID of the root cgroup is 0, but memcg treat 0 as an + * invalid ID, so we return (cgroup_id + 1). + */ + return memcg->css.cgroup->id + 1; +} + +static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short id) +{ + struct cgroup_subsys_state *css; + + css = css_from_id(id - 1, &mem_cgroup_subsys); + return mem_cgroup_from_css(css); +} + /* Writing them here to avoid exposing memcg's inner layout */ #if defined(CONFIG_INET) && defined(CONFIG_MEMCG_KMEM) @@ -2850,15 +2867,10 @@ static void __mem_cgroup_cancel_local_charge(struct mem_cgroup *memcg, */ static struct mem_cgroup *mem_cgroup_lookup(unsigned short id) { - struct cgroup_subsys_state *css; - /* ID 0 is unused ID */ if (!id) return NULL; - css = css_lookup(&mem_cgroup_subsys, id); - if (!css) - return NULL; - return mem_cgroup_from_css(css); + return mem_cgroup_from_id(id); } struct mem_cgroup *try_get_mem_cgroup_from_page(struct page *page) @@ -4368,7 +4380,7 @@ mem_cgroup_uncharge_swapcache(struct page *page, swp_entry_t ent, bool swapout) * css_get() was called in uncharge(). */ if (do_swap_account && swapout && memcg) - swap_cgroup_record(ent, css_id(&memcg->css)); + swap_cgroup_record(ent, mem_cgroup_id(memcg)); } #endif @@ -4420,8 +4432,8 @@ static int mem_cgroup_move_swap_account(swp_entry_t entry, { unsigned short old_id, new_id; - old_id = css_id(&from->css); - new_id = css_id(&to->css); + old_id = mem_cgroup_id(from); + new_id = mem_cgroup_id(to); if (swap_cgroup_cmpxchg(entry, old_id, new_id) == old_id) { mem_cgroup_swap_statistics(from, false); @@ -6571,7 +6583,7 @@ static enum mc_target_type get_mctgt_type(struct vm_area_struct *vma, } /* There is a swap entry and a page doesn't exist or isn't charged */ if (ent.val && !ret && - css_id(&mc.from->css) == lookup_swap_cgroup_id(ent)) { + mem_cgroup_id(mc.from) == lookup_swap_cgroup_id(ent)) { ret = MC_TARGET_SWAP; if (target) target->ent = ent; -- 1.8.0.2 -- 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> ^ permalink raw reply related [flat|nested] 14+ messages in thread
[parent not found: <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>]
* [PATCH v6 3/5] memcg: fail to create cgroup if the cgroup id is too big [not found] ` <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> @ 2013-09-23 8:56 ` Li Zefan 2013-09-23 8:56 ` [PATCH v6 4/5] memcg: stop using css id Li Zefan ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Li Zefan @ 2013-09-23 8:56 UTC (permalink / raw) To: Andrew Morton Cc: Tejun Heo, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org memcg requires the cgroup id to be smaller than 65536. This is a preparation to kill css id. Signed-off-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> Acked-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> --- mm/memcontrol.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 6719e2c..4e40ebe 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -498,6 +498,12 @@ static inline bool mem_cgroup_is_root(struct mem_cgroup *memcg) return (memcg == root_mem_cgroup); } +/* + * We restrict the id in the range of [1, 65535], so it can fit into + * an unsigned short. + */ +#define MEM_CGROUP_ID_MAX USHRT_MAX + static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg) { /* @@ -6312,6 +6318,9 @@ mem_cgroup_css_online(struct cgroup_subsys_state *css) struct mem_cgroup *parent = mem_cgroup_from_css(css_parent(css)); int error = 0; + if (css->cgroup->id > MEM_CGROUP_ID_MAX) + return -ENOSPC; + if (!parent) return 0; -- 1.8.0.2 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v6 4/5] memcg: stop using css id [not found] ` <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 2013-09-23 8:56 ` [PATCH v6 3/5] memcg: fail to create cgroup if the cgroup id is too big Li Zefan @ 2013-09-23 8:56 ` Li Zefan 2013-09-23 8:57 ` [PATCH v6 5/5] cgroup: kill css_id Li Zefan 2013-09-23 13:08 ` [PATCH v6 0/5] memcg, cgroup: kill css id Tejun Heo 3 siblings, 0 replies; 14+ messages in thread From: Li Zefan @ 2013-09-23 8:56 UTC (permalink / raw) To: Andrew Morton Cc: Tejun Heo, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org Now memcg uses cgroup id instead of css id. Update some comments and set mem_cgroup_subsys->use_id to 0. Signed-off-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> Acked-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> --- mm/memcontrol.c | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 4e40ebe..32b2d33 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -592,16 +592,11 @@ static void disarm_sock_keys(struct mem_cgroup *memcg) #ifdef CONFIG_MEMCG_KMEM /* * This will be the memcg's index in each cache's ->memcg_params->memcg_caches. - * There are two main reasons for not using the css_id for this: - * 1) this works better in sparse environments, where we have a lot of memcgs, - * but only a few kmem-limited. Or also, if we have, for instance, 200 - * memcgs, and none but the 200th is kmem-limited, we'd have to have a - * 200 entry array for that. - * - * 2) In order not to violate the cgroup API, we would like to do all memory - * allocation in ->create(). At that point, we haven't yet allocated the - * css_id. Having a separate index prevents us from messing with the cgroup - * core for this + * The main reason for not using cgroup id for this: + * this works better in sparse environments, where we have a lot of memcgs, + * but only a few kmem-limited. Or also, if we have, for instance, 200 + * memcgs, and none but the 200th is kmem-limited, we'd have to have a + * 200 entry array for that. * * The current size of the caches array is stored in * memcg_limited_groups_array_size. It will double each time we have to @@ -616,14 +611,14 @@ int memcg_limited_groups_array_size; * cgroups is a reasonable guess. In the future, it could be a parameter or * tunable, but that is strictly not necessary. * - * MAX_SIZE should be as large as the number of css_ids. Ideally, we could get + * MAX_SIZE should be as large as the number of cgrp_ids. Ideally, we could get * this constant directly from cgroup, but it is understandable that this is * better kept as an internal representation in cgroup.c. In any case, the - * css_id space is not getting any smaller, and we don't have to necessarily + * cgrp_id space is not getting any smaller, and we don't have to necessarily * increase ours as well if it increases. */ #define MEMCG_CACHES_MIN_SIZE 4 -#define MEMCG_CACHES_MAX_SIZE 65535 +#define MEMCG_CACHES_MAX_SIZE MEM_CGROUP_ID_MAX /* * A lot of the calls to the cache allocation functions are expected to be @@ -6215,7 +6210,6 @@ static void __mem_cgroup_free(struct mem_cgroup *memcg) size_t size = memcg_size(); mem_cgroup_remove_from_trees(memcg); - free_css_id(&mem_cgroup_subsys, &memcg->css); for_each_node(node) free_mem_cgroup_per_zone_info(memcg, node); @@ -7012,7 +7006,6 @@ struct cgroup_subsys mem_cgroup_subsys = { .bind = mem_cgroup_bind, .base_cftypes = mem_cgroup_files, .early_init = 0, - .use_id = 1, }; #ifdef CONFIG_MEMCG_SWAP -- 1.8.0.2 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v6 5/5] cgroup: kill css_id [not found] ` <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 2013-09-23 8:56 ` [PATCH v6 3/5] memcg: fail to create cgroup if the cgroup id is too big Li Zefan 2013-09-23 8:56 ` [PATCH v6 4/5] memcg: stop using css id Li Zefan @ 2013-09-23 8:57 ` Li Zefan 2013-09-23 13:08 ` [PATCH v6 0/5] memcg, cgroup: kill css id Tejun Heo 3 siblings, 0 replies; 14+ messages in thread From: Li Zefan @ 2013-09-23 8:57 UTC (permalink / raw) To: Andrew Morton Cc: Tejun Heo, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org The only user of css_id was memcg, and it has been convered to use cgroup->id, so kill css_id. Signed-off-by: Li Zefan <lizefan-Z5rXVj2qdvIAvxtiuMwx3w@public.gmane.org> Reviewed-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> Acked-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> --- include/linux/cgroup.h | 37 -------- kernel/cgroup.c | 248 +------------------------------------------------ 2 files changed, 1 insertion(+), 284 deletions(-) diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h index 3561d30..39c1d94 100644 --- a/include/linux/cgroup.h +++ b/include/linux/cgroup.h @@ -612,11 +612,6 @@ struct cgroup_subsys { int subsys_id; int disabled; int early_init; - /* - * True if this subsys uses ID. ID is not available before cgroup_init() - * (not available in early_init time.) - */ - bool use_id; /* * If %false, this subsystem is properly hierarchical - @@ -642,9 +637,6 @@ struct cgroup_subsys { */ struct cgroupfs_root *root; struct list_head sibling; - /* used when use_id == true */ - struct idr idr; - spinlock_t id_lock; /* list of cftype_sets */ struct list_head cftsets; @@ -875,35 +867,6 @@ int css_scan_tasks(struct cgroup_subsys_state *css, int cgroup_attach_task_all(struct task_struct *from, struct task_struct *); int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from); -/* - * CSS ID is ID for cgroup_subsys_state structs under subsys. This only works - * if cgroup_subsys.use_id == true. It can be used for looking up and scanning. - * CSS ID is assigned at cgroup allocation (create) automatically - * and removed when subsys calls free_css_id() function. This is because - * the lifetime of cgroup_subsys_state is subsys's matter. - * - * Looking up and scanning function should be called under rcu_read_lock(). - * Taking cgroup_mutex is not necessary for following calls. - * But the css returned by this routine can be "not populated yet" or "being - * destroyed". The caller should check css and cgroup's status. - */ - -/* - * Typically Called at ->destroy(), or somewhere the subsys frees - * cgroup_subsys_state. - */ -void free_css_id(struct cgroup_subsys *ss, struct cgroup_subsys_state *css); - -/* Find a cgroup_subsys_state which has given ID */ - -struct cgroup_subsys_state *css_lookup(struct cgroup_subsys *ss, int id); - -/* Returns true if root is ancestor of cg */ -bool css_is_ancestor(struct cgroup_subsys_state *cg, - const struct cgroup_subsys_state *root); - -/* Get id and depth of css */ -unsigned short css_id(struct cgroup_subsys_state *css); struct cgroup_subsys_state *css_from_dir(struct dentry *dentry, struct cgroup_subsys *ss); diff --git a/kernel/cgroup.c b/kernel/cgroup.c index b3ffe76..41f71c3 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -125,38 +125,6 @@ struct cfent { }; /* - * CSS ID -- ID per subsys's Cgroup Subsys State(CSS). used only when - * cgroup_subsys->use_id != 0. - */ -#define CSS_ID_MAX (65535) -struct css_id { - /* - * The css to which this ID points. This pointer is set to valid value - * after cgroup is populated. If cgroup is removed, this will be NULL. - * This pointer is expected to be RCU-safe because destroy() - * is called after synchronize_rcu(). But for safe use, css_tryget() - * should be used for avoiding race. - */ - struct cgroup_subsys_state __rcu *css; - /* - * ID of this css. - */ - unsigned short id; - /* - * Depth in hierarchy which this ID belongs to. - */ - unsigned short depth; - /* - * ID is freed by RCU. (and lookup routine is RCU safe.) - */ - struct rcu_head rcu_head; - /* - * Hierarchy of CSS ID belongs to. - */ - unsigned short stack[0]; /* Array of Length (depth+1) */ -}; - -/* * cgroup_event represents events which userspace want to receive. */ struct cgroup_event { @@ -387,9 +355,6 @@ struct cgrp_cset_link { static struct css_set init_css_set; static struct cgrp_cset_link init_cgrp_cset_link; -static int cgroup_init_idr(struct cgroup_subsys *ss, - struct cgroup_subsys_state *css); - /* * css_set_lock protects the list of css_set objects, and the chain of * tasks off each css_set. Nests outside task->alloc_lock due to @@ -841,8 +806,6 @@ static struct backing_dev_info cgroup_backing_dev_info = { .capabilities = BDI_CAP_NO_ACCT_AND_WRITEBACK, }; -static int alloc_css_id(struct cgroup_subsys_state *child_css); - static struct inode *cgroup_new_inode(umode_t mode, struct super_block *sb) { struct inode *inode = new_inode(sb); @@ -4240,21 +4203,6 @@ static int cgroup_populate_dir(struct cgroup *cgrp, unsigned long subsys_mask) goto err; } } - - /* This cgroup is ready now */ - for_each_root_subsys(cgrp->root, ss) { - struct cgroup_subsys_state *css = cgroup_css(cgrp, ss); - struct css_id *id = rcu_dereference_protected(css->id, true); - - /* - * Update id->css pointer and make this css visible from - * CSS ID functions. This pointer will be dereferened - * from RCU-read-side without locks. - */ - if (id) - rcu_assign_pointer(id->css, css); - } - return 0; err: cgroup_clear_dir(cgrp, subsys_mask); @@ -4323,7 +4271,6 @@ static void init_css(struct cgroup_subsys_state *css, struct cgroup_subsys *ss, css->cgroup = cgrp; css->ss = ss; css->flags = 0; - css->id = NULL; if (cgrp->parent) css->parent = cgroup_css(cgrp->parent, ss); @@ -4455,12 +4402,6 @@ static long cgroup_create(struct cgroup *parent, struct dentry *dentry, goto err_free_all; init_css(css, ss, cgrp); - - if (ss->use_id) { - err = alloc_css_id(css); - if (err) - goto err_free_all; - } } /* @@ -4925,12 +4866,6 @@ int __init_or_module cgroup_load_subsys(struct cgroup_subsys *ss) /* our new subsystem will be attached to the dummy hierarchy. */ init_css(css, ss, cgroup_dummy_top); - /* init_idr must be after init_css() because it sets css->id. */ - if (ss->use_id) { - ret = cgroup_init_idr(ss, css); - if (ret) - goto err_unload; - } /* * Now we need to entangle the css into the existing css_sets. unlike @@ -4996,9 +4931,6 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss) offline_css(cgroup_css(cgroup_dummy_top, ss)); - if (ss->use_id) - idr_destroy(&ss->idr); - /* deassign the subsys_id */ cgroup_subsys[ss->subsys_id] = NULL; @@ -5025,8 +4957,7 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss) /* * remove subsystem's css from the cgroup_dummy_top and free it - * need to free before marking as null because ss->css_free needs - * the cgrp->subsys pointer to find their state. note that this - * also takes care of freeing the css_id. + * the cgrp->subsys pointer to find their state. */ ss->css_free(cgroup_css(cgroup_dummy_top, ss)); RCU_INIT_POINTER(cgroup_dummy_top->subsys[ss->subsys_id], NULL); @@ -5097,8 +5028,6 @@ int __init cgroup_init(void) for_each_builtin_subsys(ss, i) { if (!ss->early_init) cgroup_init_subsys(ss); - if (ss->use_id) - cgroup_init_idr(ss, init_css_set.subsys[ss->subsys_id]); } /* allocate id for the dummy hierarchy */ @@ -5518,181 +5447,6 @@ static int __init cgroup_disable(char *str) } __setup("cgroup_disable=", cgroup_disable); -/* - * Functons for CSS ID. - */ - -/* to get ID other than 0, this should be called when !cgroup_is_dead() */ -unsigned short css_id(struct cgroup_subsys_state *css) -{ - struct css_id *cssid; - - /* - * This css_id() can return correct value when somone has refcnt - * on this or this is under rcu_read_lock(). Once css->id is allocated, - * it's unchanged until freed. - */ - cssid = rcu_dereference_raw(css->id); - - if (cssid) - return cssid->id; - return 0; -} -EXPORT_SYMBOL_GPL(css_id); - -/** - * css_is_ancestor - test "root" css is an ancestor of "child" - * @child: the css to be tested. - * @root: the css supporsed to be an ancestor of the child. - * - * Returns true if "root" is an ancestor of "child" in its hierarchy. Because - * this function reads css->id, the caller must hold rcu_read_lock(). - * But, considering usual usage, the csses should be valid objects after test. - * Assuming that the caller will do some action to the child if this returns - * returns true, the caller must take "child";s reference count. - * If "child" is valid object and this returns true, "root" is valid, too. - */ - -bool css_is_ancestor(struct cgroup_subsys_state *child, - const struct cgroup_subsys_state *root) -{ - struct css_id *child_id; - struct css_id *root_id; - - child_id = rcu_dereference(child->id); - if (!child_id) - return false; - root_id = rcu_dereference(root->id); - if (!root_id) - return false; - if (child_id->depth < root_id->depth) - return false; - if (child_id->stack[root_id->depth] != root_id->id) - return false; - return true; -} - -void free_css_id(struct cgroup_subsys *ss, struct cgroup_subsys_state *css) -{ - struct css_id *id = rcu_dereference_protected(css->id, true); - - /* When this is called before css_id initialization, id can be NULL */ - if (!id) - return; - - BUG_ON(!ss->use_id); - - rcu_assign_pointer(id->css, NULL); - rcu_assign_pointer(css->id, NULL); - spin_lock(&ss->id_lock); - idr_remove(&ss->idr, id->id); - spin_unlock(&ss->id_lock); - kfree_rcu(id, rcu_head); -} -EXPORT_SYMBOL_GPL(free_css_id); - -/* - * This is called by init or create(). Then, calls to this function are - * always serialized (By cgroup_mutex() at create()). - */ - -static struct css_id *get_new_cssid(struct cgroup_subsys *ss, int depth) -{ - struct css_id *newid; - int ret, size; - - BUG_ON(!ss->use_id); - - size = sizeof(*newid) + sizeof(unsigned short) * (depth + 1); - newid = kzalloc(size, GFP_KERNEL); - if (!newid) - return ERR_PTR(-ENOMEM); - - idr_preload(GFP_KERNEL); - spin_lock(&ss->id_lock); - /* Don't use 0. allocates an ID of 1-65535 */ - ret = idr_alloc(&ss->idr, newid, 1, CSS_ID_MAX + 1, GFP_NOWAIT); - spin_unlock(&ss->id_lock); - idr_preload_end(); - - /* Returns error when there are no free spaces for new ID.*/ - if (ret < 0) - goto err_out; - - newid->id = ret; - newid->depth = depth; - return newid; -err_out: - kfree(newid); - return ERR_PTR(ret); - -} - -static int __init_or_module cgroup_init_idr(struct cgroup_subsys *ss, - struct cgroup_subsys_state *rootcss) -{ - struct css_id *newid; - - spin_lock_init(&ss->id_lock); - idr_init(&ss->idr); - - newid = get_new_cssid(ss, 0); - if (IS_ERR(newid)) - return PTR_ERR(newid); - - newid->stack[0] = newid->id; - RCU_INIT_POINTER(newid->css, rootcss); - RCU_INIT_POINTER(rootcss->id, newid); - return 0; -} - -static int alloc_css_id(struct cgroup_subsys_state *child_css) -{ - struct cgroup_subsys_state *parent_css = css_parent(child_css); - struct css_id *child_id, *parent_id; - int i, depth; - - parent_id = rcu_dereference_protected(parent_css->id, true); - depth = parent_id->depth + 1; - - child_id = get_new_cssid(child_css->ss, depth); - if (IS_ERR(child_id)) - return PTR_ERR(child_id); - - for (i = 0; i < depth; i++) - child_id->stack[i] = parent_id->stack[i]; - child_id->stack[depth] = child_id->id; - /* - * child_id->css pointer will be set after this cgroup is available - * see cgroup_populate_dir() - */ - rcu_assign_pointer(child_css->id, child_id); - - return 0; -} - -/** - * css_lookup - lookup css by id - * @ss: cgroup subsys to be looked into. - * @id: the id - * - * Returns pointer to cgroup_subsys_state if there is valid one with id. - * NULL if not. Should be called under rcu_read_lock() - */ -struct cgroup_subsys_state *css_lookup(struct cgroup_subsys *ss, int id) -{ - struct css_id *cssid = NULL; - - BUG_ON(!ss->use_id); - cssid = idr_find(&ss->idr, id); - - if (unlikely(!cssid)) - return NULL; - - return rcu_dereference(cssid->css); -} -EXPORT_SYMBOL_GPL(css_lookup); - /** * css_from_dir - get corresponding css from the dentry of a cgroup dir * @dentry: directory dentry of interest -- 1.8.0.2 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id [not found] ` <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> ` (2 preceding siblings ...) 2013-09-23 8:57 ` [PATCH v6 5/5] cgroup: kill css_id Li Zefan @ 2013-09-23 13:08 ` Tejun Heo [not found] ` <20130923130816.GH30946-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 3 siblings, 1 reply; 14+ messages in thread From: Tejun Heo @ 2013-09-23 13:08 UTC (permalink / raw) To: Li Zefan Cc: Andrew Morton, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org Hello, On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: > The whole patchset has been acked and reviewed by Michal and Tejun. > Could you merge it into mm tree? Ah... I really hoped that this had been merged during -rc1 window. Andrew, would it be okay to carry this series through cgroup tree? It doesn't really have much to do with mm proper and it's a PITA to have to keep updating css_id code from cgroup side when it's scheduled to go away. If carried in -mm, it's likely to cause conflicts with ongoing cgroup changes too. Thanks. -- tejun ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20130923130816.GH30946-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>]
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id [not found] ` <20130923130816.GH30946-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> @ 2013-09-23 13:12 ` Tejun Heo 2013-09-24 0:32 ` Li Zefan 0 siblings, 1 reply; 14+ messages in thread From: Tejun Heo @ 2013-09-23 13:12 UTC (permalink / raw) To: Li Zefan Cc: Andrew Morton, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org On Mon, Sep 23, 2013 at 09:08:16AM -0400, Tejun Heo wrote: > Hello, > > On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: > > The whole patchset has been acked and reviewed by Michal and Tejun. > > Could you merge it into mm tree? > > Ah... I really hoped that this had been merged during -rc1 window. > Andrew, would it be okay to carry this series through cgroup tree? It > doesn't really have much to do with mm proper and it's a PITA to have > to keep updating css_id code from cgroup side when it's scheduled to > go away. If carried in -mm, it's likely to cause conflicts with > ongoing cgroup changes too. Also, wasn't this already in -mm during the last devel cycle? ISTR conflicts with it in -mm with other cgroup core changes. Is there any specific reason why this wasn't merged during the merge windw? Thanks. -- tejun ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id 2013-09-23 13:12 ` Tejun Heo @ 2013-09-24 0:32 ` Li Zefan [not found] ` <5240DD83.1070509-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Li Zefan @ 2013-09-24 0:32 UTC (permalink / raw) To: Tejun Heo Cc: Andrew Morton, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm@kvack.org On 2013/9/23 21:12, Tejun Heo wrote: > On Mon, Sep 23, 2013 at 09:08:16AM -0400, Tejun Heo wrote: >> Hello, >> >> On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: >>> The whole patchset has been acked and reviewed by Michal and Tejun. >>> Could you merge it into mm tree? >> >> Ah... I really hoped that this had been merged during -rc1 window. >> Andrew, would it be okay to carry this series through cgroup tree? It >> doesn't really have much to do with mm proper and it's a PITA to have >> to keep updating css_id code from cgroup side when it's scheduled to >> go away. If carried in -mm, it's likely to cause conflicts with >> ongoing cgroup changes too. I would love to see this patchset go through cgroup tree. The changes to memcg is quite small, and as -mm tree is based on -next it won't cause future conflicts. > > Also, wasn't this already in -mm during the last devel cycle? ISTR > conflicts with it in -mm with other cgroup core changes. Is there any > specific reason why this wasn't merged during the merge windw? > No, it never went into -mm tree... I guess it's because Andrew was too busy and overlooked this patchset? -- 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <5240DD83.1070509-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id [not found] ` <5240DD83.1070509-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> @ 2013-09-24 0:52 ` Andrew Morton 2013-09-24 1:30 ` Tejun Heo 0 siblings, 1 reply; 14+ messages in thread From: Andrew Morton @ 2013-09-24 0:52 UTC (permalink / raw) To: Li Zefan Cc: Tejun Heo, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org On Tue, 24 Sep 2013 08:32:03 +0800 Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote: > On 2013/9/23 21:12, Tejun Heo wrote: > > On Mon, Sep 23, 2013 at 09:08:16AM -0400, Tejun Heo wrote: > >> Hello, > >> > >> On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: > >>> The whole patchset has been acked and reviewed by Michal and Tejun. > >>> Could you merge it into mm tree? > >> > >> Ah... I really hoped that this had been merged during -rc1 window. > >> Andrew, would it be okay to carry this series through cgroup tree? It > >> doesn't really have much to do with mm proper and it's a PITA to have > >> to keep updating css_id code from cgroup side when it's scheduled to > >> go away. If carried in -mm, it's likely to cause conflicts with > >> ongoing cgroup changes too. > > I would love to see this patchset go through cgroup tree. The changes to > memcg is quite small, It seems logical to put this in the cgroup tree as that's where most of the impact occurs. > and as -mm tree is based on -next it won't cause > future conflicts. That's no longer the case - I'm staging -mm patches ahead of linux-next now. Except in cases where that's impractical, such as the 3.12 memcg changes which were pretty heavily impacted by cgroups tree changes. > > > > Also, wasn't this already in -mm during the last devel cycle? ISTR > > conflicts with it in -mm with other cgroup core changes. Is there any > > specific reason why this wasn't merged during the merge windw? > > > > No, it never went into -mm tree... I guess it's because Andrew was too > busy and overlooked this patchset? I'm not sure what happened to the August 7 patchset, actually. I don't often overlook stuff - I'll skip things if the timing is terrible or if the review comments indicate that another version is coming. But none of that seems to be the case here. hmm... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id 2013-09-24 0:52 ` Andrew Morton @ 2013-09-24 1:30 ` Tejun Heo 2013-09-24 1:52 ` Tejun Heo 0 siblings, 1 reply; 14+ messages in thread From: Tejun Heo @ 2013-09-24 1:30 UTC (permalink / raw) To: Andrew Morton Cc: Li Zefan, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm@kvack.org Hello, Andrew. On Mon, Sep 23, 2013 at 05:52:47PM -0700, Andrew Morton wrote: > > I would love to see this patchset go through cgroup tree. The changes to > > memcg is quite small, > > It seems logical to put this in the cgroup tree as that's where most of > the impact occurs. Cool, applying the changes to cgroup/for-3.13. > > and as -mm tree is based on -next it won't cause > > future conflicts. > > That's no longer the case - I'm staging -mm patches ahead of linux-next > now. Except in cases where that's impractical, such as the 3.12 memcg > changes which were pretty heavily impacted by cgroups tree changes. Please note that cgroup is likely to continue to go through a lot of changes for the foreseeable future and memcg is likely to be affected heavily. Thanks. -- tejun -- 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id 2013-09-24 1:30 ` Tejun Heo @ 2013-09-24 1:52 ` Tejun Heo [not found] ` <20130924015211.GD3482-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Tejun Heo @ 2013-09-24 1:52 UTC (permalink / raw) To: Andrew Morton Cc: Li Zefan, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm@kvack.org, Stephen Rothwell (cc'ing Stephen, hi!) On Mon, Sep 23, 2013 at 09:30:58PM -0400, Tejun Heo wrote: > Hello, Andrew. > > On Mon, Sep 23, 2013 at 05:52:47PM -0700, Andrew Morton wrote: > > > I would love to see this patchset go through cgroup tree. The changes to > > > memcg is quite small, > > > > It seems logical to put this in the cgroup tree as that's where most of > > the impact occurs. > > Cool, applying the changes to cgroup/for-3.13. Stephen, Andrew, cgroup/for-3.13 will cause a minor conflict in mm/memcontrol.c with the patch which reverts Michal's reclaim changes. static void __mem_cgroup_free(struct mem_cgroup *memcg) { int node; size_t size = memcg_size(); <<<<<<< HEAD ======= mem_cgroup_remove_from_trees(memcg); free_css_id(&mem_cgroup_subsys, &memcg->css); >>>>>>> 1fa8f71dfa6e28c89afad7ac71dcb19b8c8da8b7 for_each_node(node) free_mem_cgroup_per_zone_info(memcg, node); It's a context conflict and just removing free_css_id() call resolves it. static void __mem_cgroup_free(struct mem_cgroup *memcg) { int node; size_t size = memcg_size(); mem_cgroup_remove_from_trees(memcg); for_each_node(node) free_mem_cgroup_per_zone_info(memcg, node); Thanks. -- tejun -- 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20130924015211.GD3482-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>]
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id [not found] ` <20130924015211.GD3482-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> @ 2013-09-24 1:54 ` Stephen Rothwell 0 siblings, 0 replies; 14+ messages in thread From: Stephen Rothwell @ 2013-09-24 1:54 UTC (permalink / raw) To: Tejun Heo Cc: Andrew Morton, Li Zefan, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 1592 bytes --] Hi Tejun, On Mon, 23 Sep 2013 21:52:11 -0400 Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > > (cc'ing Stephen, hi!) Hi :-) > On Mon, Sep 23, 2013 at 09:30:58PM -0400, Tejun Heo wrote: > > > > On Mon, Sep 23, 2013 at 05:52:47PM -0700, Andrew Morton wrote: > > > > I would love to see this patchset go through cgroup tree. The changes to > > > > memcg is quite small, > > > > > > It seems logical to put this in the cgroup tree as that's where most of > > > the impact occurs. > > > > Cool, applying the changes to cgroup/for-3.13. > > Stephen, Andrew, cgroup/for-3.13 will cause a minor conflict in > mm/memcontrol.c with the patch which reverts Michal's reclaim changes. > > static void __mem_cgroup_free(struct mem_cgroup *memcg) > { > int node; > size_t size = memcg_size(); > > <<<<<<< HEAD > ======= > mem_cgroup_remove_from_trees(memcg); > free_css_id(&mem_cgroup_subsys, &memcg->css); > > >>>>>>> 1fa8f71dfa6e28c89afad7ac71dcb19b8c8da8b7 > for_each_node(node) > free_mem_cgroup_per_zone_info(memcg, node); > > It's a context conflict and just removing free_css_id() call resolves > it. > > static void __mem_cgroup_free(struct mem_cgroup *memcg) > { > int node; > size_t size = memcg_size(); > > mem_cgroup_remove_from_trees(memcg); > > for_each_node(node) > free_mem_cgroup_per_zone_info(memcg, node); Thanks for the heads up, I guess I'll see that tomorrow. -- Cheers, Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/5] memcg, cgroup: kill css id 2013-09-23 8:55 [PATCH v6 0/5] memcg, cgroup: kill css id Li Zefan ` (2 preceding siblings ...) [not found] ` <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> @ 2013-09-24 1:46 ` Tejun Heo 3 siblings, 0 replies; 14+ messages in thread From: Tejun Heo @ 2013-09-24 1:46 UTC (permalink / raw) To: Li Zefan Cc: Andrew Morton, Michal Hocko, KAMEZAWA Hiroyuki, Johannes Weiner, LKML, cgroups, linux-mm@kvack.org On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: > Hi Andrew, > > The whole patchset has been acked and reviewed by Michal and Tejun. > Could you merge it into mm tree? > > =========== > > This patchset converts memcg to use cgroup->id, and then we remove cgroup > css_id. Applied to cgroup/for-3.13. Thanks. -- tejun -- 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-09-24 1:54 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-23 8:55 [PATCH v6 0/5] memcg, cgroup: kill css id Li Zefan
2013-09-23 8:55 ` [PATCH v6 1/5] memcg: convert to use cgroup_is_descendant() Li Zefan
2013-09-23 8:56 ` [PATCH v6 2/5] memcg: convert to use cgroup id Li Zefan
[not found] ` <524001F8.6070205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-09-23 8:56 ` [PATCH v6 3/5] memcg: fail to create cgroup if the cgroup id is too big Li Zefan
2013-09-23 8:56 ` [PATCH v6 4/5] memcg: stop using css id Li Zefan
2013-09-23 8:57 ` [PATCH v6 5/5] cgroup: kill css_id Li Zefan
2013-09-23 13:08 ` [PATCH v6 0/5] memcg, cgroup: kill css id Tejun Heo
[not found] ` <20130923130816.GH30946-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-09-23 13:12 ` Tejun Heo
2013-09-24 0:32 ` Li Zefan
[not found] ` <5240DD83.1070509-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-09-24 0:52 ` Andrew Morton
2013-09-24 1:30 ` Tejun Heo
2013-09-24 1:52 ` Tejun Heo
[not found] ` <20130924015211.GD3482-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-09-24 1:54 ` Stephen Rothwell
2013-09-24 1:46 ` Tejun Heo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox