From: Vladimir Davydov <vdavydov@parallels.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: akpm@linux-foundation.org, rientjes@google.com,
penberg@kernel.org, cl@linux.com, glommer@gmail.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
devel@openvz.org
Subject: Re: [PATCH 1/8] memcg: export kmemcg cache id via cgroup fs
Date: Tue, 4 Feb 2014 18:49:59 +0400 [thread overview]
Message-ID: <52F0FE17.1050109@parallels.com> (raw)
In-Reply-To: <20140204144033.GE4890@dhcp22.suse.cz>
On 02/04/2014 06:40 PM, Michal Hocko wrote:
> On Sun 02-02-14 20:33:46, Vladimir Davydov wrote:
>> Per-memcg kmem caches are named as follows:
>>
>> <global-cache-name>(<cgroup-kmem-id>:<cgroup-name>)
>>
>> where <cgroup-kmem-id> is the unique id of the memcg the cache belongs
>> to, <cgroup-name> is the relative name of the memcg on the cgroup fs.
>> Cache names are exposed to userspace for debugging purposes (e.g. via
>> sysfs in case of slub or via dmesg).
> If this is only for debugging purposes then it shouldn't pollute regular
> memcg cgroupfs namespace.
>
>> Using relative names makes it impossible in general (in case the cgroup
>> hierarchy is not flat) to find out which memcg a particular cache
>> belongs to, because <cgroup-kmem-id> is not known to the user. Since
>> using absolute cgroup names would be an overkill,
> I do not consider it an overkill. We are using the full path when
> dumping OOM information so I do not see any reason this should be any
> different.
When we dump information, we simply print the cgroup path to dmesg and
forget about it while the memcg cache's name will leave at least until
the memcg is destroyed. Basically that means PATH_MAX *
NR_KMEM_ACTIVE_MEMCGS * NR_SLAB_CACHES memory overhead at max.
Anyway, I decided to drop this patch, so please see version 2 of this
patchset (you must be in CC):
https://lkml.org/lkml/2014/2/3/268
Thanks.
>
>> let's fix this by
>> exporting the id of kmem-active memcg via cgroup fs file
>> "memory.kmem.id".
>>
>> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
> Nacked-by: Michal Hocko <mhocko@suse.cz>
>
>> ---
>> mm/memcontrol.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 53385cd4e6f0..91d242707404 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -3113,6 +3113,14 @@ int memcg_cache_id(struct mem_cgroup *memcg)
>> return memcg ? memcg->kmemcg_id : -1;
>> }
>>
>> +static s64 mem_cgroup_cache_id_read(struct cgroup_subsys_state *css,
>> + struct cftype *cft)
>> +{
>> + struct mem_cgroup *memcg = mem_cgroup_from_css(css);
>> +
>> + return memcg_can_account_kmem(memcg) ? memcg_cache_id(memcg) : -1;
>> +}
>> +
>> static size_t memcg_caches_array_size(int num_groups)
>> {
>> ssize_t size;
>> @@ -6301,6 +6309,10 @@ static struct cftype mem_cgroup_files[] = {
>> #endif
>> #ifdef CONFIG_MEMCG_KMEM
>> {
>> + .name = "kmem.id",
>> + .read_s64 = mem_cgroup_cache_id_read,
>> + },
>> + {
>> .name = "kmem.limit_in_bytes",
>> .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT),
>> .write_string = mem_cgroup_write,
>> --
>> 1.7.10.4
>>
--
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>
next prev parent reply other threads:[~2014-02-04 14:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-02 16:33 [PATCH 0/8] memcg-vs-slab related fixes, improvements, cleanups Vladimir Davydov
2014-02-02 16:33 ` [PATCH 1/8] memcg: export kmemcg cache id via cgroup fs Vladimir Davydov
2014-02-03 6:21 ` David Rientjes
2014-02-03 6:57 ` Vladimir Davydov
2014-02-03 7:19 ` Vladimir Davydov
2014-02-03 10:05 ` Glauber Costa
2014-02-03 13:01 ` Vladimir Davydov
2014-02-03 11:04 ` David Rientjes
2014-02-03 13:00 ` Vladimir Davydov
2014-02-04 14:44 ` Michal Hocko
2014-02-04 14:40 ` Michal Hocko
2014-02-04 14:49 ` Vladimir Davydov [this message]
2014-02-02 16:33 ` [PATCH 2/8] memcg, slab: remove cgroup name from memcg cache names Vladimir Davydov
2014-02-04 14:45 ` Michal Hocko
2014-02-04 15:11 ` Vladimir Davydov
2014-02-04 15:13 ` Michal Hocko
2014-02-02 16:33 ` [PATCH 3/8] memcg, slab: never try to merge memcg caches Vladimir Davydov
2014-02-04 14:52 ` Michal Hocko
2014-02-04 14:59 ` Vladimir Davydov
2014-02-04 15:11 ` Michal Hocko
2014-02-04 15:27 ` Vladimir Davydov
2014-02-04 15:43 ` Glauber Costa
2014-02-04 16:04 ` Vladimir Davydov
2014-02-04 16:10 ` Glauber Costa
2014-02-06 14:07 ` Michal Hocko
2014-02-06 14:15 ` Vladimir Davydov
2014-02-06 15:29 ` Michal Hocko
2014-02-06 15:39 ` Vladimir Davydov
2014-02-02 16:33 ` [PATCH 4/8] memcg, slab: separate memcg vs root cache creation paths Vladimir Davydov
2014-02-02 16:33 ` [PATCH 5/8] slub: adjust memcg caches when creating cache alias Vladimir Davydov
2014-02-02 16:33 ` [PATCH 6/8] slub: rework sysfs layout for memcg caches Vladimir Davydov
2014-02-02 16:33 ` [PATCH 7/8] memcg, slab: unregister cache from memcg before starting to destroy it Vladimir Davydov
2014-02-02 16:33 ` [PATCH 8/8] memcg, slab: do not destroy children caches if parent has aliases Vladimir Davydov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52F0FE17.1050109@parallels.com \
--to=vdavydov@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=devel@openvz.org \
--cc=glommer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox