I need this in the next patch. Signed-off-by: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx> --- mm/memcontrol.c | 114 +++++++++++++++++++++++++++---------------------------- 1 file changed, 56 insertions(+), 58 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index fb25575bdb22..21cf15184ad8 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -391,6 +391,45 @@ struct mem_cgroup { }; #ifdef CONFIG_MEMCG_KMEM +/* + * This will be the memcg's index in each cache's ->memcg_params->memcg_caches. + * 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 + * increase it. + */ +static DEFINE_IDA(kmem_limited_groups); +int memcg_limited_groups_array_size; + +/* + * MIN_SIZE is different than 1, because we would like to avoid going through + * the alloc/free process all the time. In a small machine, 4 kmem-limited + * 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 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 + * 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 MEM_CGROUP_ID_MAX + +/* + * A lot of the calls to the cache allocation functions are expected to be + * inlined by the compiler. Since the calls to memcg_kmem_get_cache are + * conditional to this static branch, we'll have to allow modules that does + * kmem_cache_alloc and the such to see this symbol as well + */ +struct static_key memcg_kmem_enabled_key; +EXPORT_SYMBOL(memcg_kmem_enabled_key); + static bool memcg_kmem_is_active(struct mem_cgroup *memcg) { return memcg->kmem_ctx->active; @@ -433,6 +472,19 @@ static void memcg_release_kmem_context(struct mem_cgroup *memcg) { kfree(memcg->kmem_ctx); } + +static void disarm_kmem_keys(struct mem_cgroup *memcg) +{ + if (memcg_kmem_is_active(memcg)) { + static_key_slow_dec(&memcg_kmem_enabled_key); + ida_simple_remove(&kmem_limited_groups, memcg->kmemcg_id); + } + /* + * This check can't live in kmem destruction function, + * since the charges will outlive the cgroup + */ + WARN_ON(res_counter_read_u64(&memcg->kmem, RES_USAGE) != 0); +} #else static int memcg_alloc_kmem_context(struct mem_cgroup *memcg) { @@ -442,6 +494,10 @@ static int memcg_alloc_kmem_context(struct mem_cgroup *memcg) static void memcg_release_kmem_context(struct mem_cgroup *memcg) { } + +static void disarm_kmem_keys(struct mem_cgroup *memcg) +{ +} #endif /* CONFIG_MEMCG_KMEM */ /* Stuffs for move charges at task migration. */ @@ -636,64 +692,6 @@ static void disarm_sock_keys(struct mem_cgroup *memcg) } #endif -#ifdef CONFIG_MEMCG_KMEM -/* - * This will be the memcg's index in each cache's ->memcg_params->memcg_caches. - * 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 - * increase it. - */ -static DEFINE_IDA(kmem_limited_groups); -int memcg_limited_groups_array_size; - -/* - * MIN_SIZE is different than 1, because we would like to avoid going through - * the alloc/free process all the time. In a small machine, 4 kmem-limited - * 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 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 - * 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 MEM_CGROUP_ID_MAX - -/* - * A lot of the calls to the cache allocation functions are expected to be - * inlined by the compiler. Since the calls to memcg_kmem_get_cache are - * conditional to this static branch, we'll have to allow modules that does - * kmem_cache_alloc and the such to see this symbol as well - */ -struct static_key memcg_kmem_enabled_key; -EXPORT_SYMBOL(memcg_kmem_enabled_key); - -static void disarm_kmem_keys(struct mem_cgroup *memcg) -{ - if (memcg_kmem_is_active(memcg)) { - static_key_slow_dec(&memcg_kmem_enabled_key); - ida_simple_remove(&kmem_limited_groups, memcg->kmemcg_id); - } - /* - * This check can't live in kmem destruction function, - * since the charges will outlive the cgroup - */ - WARN_ON(res_counter_read_u64(&memcg->kmem, RES_USAGE) != 0); -} -#else -static void disarm_kmem_keys(struct mem_cgroup *memcg) -{ -} -#endif /* CONFIG_MEMCG_KMEM */ - static void disarm_static_keys(struct mem_cgroup *memcg) { disarm_sock_keys(memcg); -- 1.7.10.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>