On Mon, Feb 3, 2014 at 10:57 AM, Vladimir Davydov
vdavy...@parallels.com wrote:
On 02/03/2014 10:21 AM, David Rientjes wrote:
On Sun, 2 Feb 2014, 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
On 02/03/2014 03:04 PM, David Rientjes wrote:
On Mon, 3 Feb 2014, Vladimir Davydov wrote:
AFAIU, cgroup identifiers dumped on oom (cgroup paths, currently) and
memcg slab cache names serve for different purposes.
Sure, you may dump the name for a number of legitimate reasons, but the
On 02/03/2014 02:05 PM, Glauber Costa wrote:
On Mon, Feb 3, 2014 at 10:57 AM, Vladimir Davydov
vdavy...@parallels.com wrote:
On 02/03/2014 10:21 AM, David Rientjes wrote:
On Sun, 2 Feb 2014, Vladimir Davydov wrote:
Per-memcg kmem caches are named as follows:
Suppose we are creating memcg cache A that could be merged with cache B
of the same memcg. Since any memcg cache has the same parameters as its
parent cache, parent caches PA and PB of memcg caches A and B must be
mergeable too. That means PA was merged with PB on creation or vice
versa, i.e. PA =
Hi,
This patch set mostly cleanups memcg slab caches creation/destruction
paths fixing a couple of bugs in the meanwhile. The only serious change
it introduces is a rework of the sysfs layout for memcg slub caches (see
patch 7).
Changes in v2:
- do not remove cgroup name part from memcg cache
Memcg-awareness turned kmem_cache_create() into a dirty interweaving of
memcg-only and except-for-memcg calls. To clean this up, let's create a
separate function handling memcg caches creation. Although this will
result in the two functions having several hunks of practically the same
code, I
Currently, memcg_unregister_cache(), which deletes the cache being
destroyed from the memcg_slab_caches list, is called after
__kmem_cache_shutdown() (see kmem_cache_destroy()), which starts to
destroy the cache. As a result, one can access a partially destroyed
cache while traversing a
Currently we destroy children caches at the very beginning of
kmem_cache_destroy(). This is wrong, because the root cache will not
necessarily be destroyed in the end - if it has aliases (refcount 0),
kmem_cache_destroy() will simply decrement its refcount and return. In
this case, at best we
The way memcg_create_kmem_cache() creates the name for a memcg cache
looks rather strange: it first formats the name in the static buffer
tmp_name protected by a mutex, then passes the pointer to the buffer to
kmem_cache_create_memcg(), which finally duplicates it to the cache
name.
Let's clean
Otherwise, kzalloc() called from a memcg won't clear the whole object.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
---
mm/slub.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/mm/slub.c b/mm/slub.c
index 8659e7184338..f3d2ef725ed6 100644
--- a/mm/slub.c
+++
Currently, we try to arrange sysfs entries for memcg caches in the same
manner as for global caches. Apart from turning /sys/kernel/slab into a
mess when there are a lot of kmem-active memcgs created, it actually
does not work properly - we won't create more than one link to a memcg
cache in case
On Mon, 3 Feb 2014 19:54:37 +0400 Vladimir Davydov vdavy...@parallels.com
wrote:
The way memcg_create_kmem_cache() creates the name for a memcg cache
looks rather strange: it first formats the name in the static buffer
tmp_name protected by a mutex, then passes the pointer to the buffer to
On 02/04/2014 02:08 AM, Andrew Morton wrote:
On Mon, 3 Feb 2014 19:54:37 +0400 Vladimir Davydov vdavy...@parallels.com
wrote:
The way memcg_create_kmem_cache() creates the name for a memcg cache
looks rather strange: it first formats the name in the static buffer
tmp_name protected by a
13 matches
Mail list logo
