From: Johannes Weiner <hannes@cmpxchg.org>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: mhocko@suse.cz, akpm@linux-foundation.org, glommer@gmail.com,
cl@linux-foundation.org, penberg@kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
devel@openvz.org
Subject: Re: [PATCH RFC -mm v2 3/3] memcg, slab: simplify synchronization scheme
Date: Fri, 18 Apr 2014 10:17:34 -0400 [thread overview]
Message-ID: <20140418141734.GD26283@cmpxchg.org> (raw)
In-Reply-To: <c3c36df83d582f8fac94bb716b82406e24229cad.1397804745.git.vdavydov@parallels.com>
I like this patch, but the API names are confusing. Could we fix up
that whole thing by any chance? Some suggestions below, but they
might only be marginally better...
On Fri, Apr 18, 2014 at 12:04:49PM +0400, Vladimir Davydov wrote:
> @@ -3156,24 +3157,34 @@ void memcg_free_cache_params(struct kmem_cache *s)
> kfree(s->memcg_params);
> }
>
> -void memcg_register_cache(struct kmem_cache *s)
> +static void memcg_kmem_create_cache(struct mem_cgroup *memcg,
> + struct kmem_cache *root_cache)
memcg_copy_kmem_cache()?
> @@ -3182,49 +3193,30 @@ void memcg_register_cache(struct kmem_cache *s)
> */
> smp_wmb();
>
> - /*
> - * Initialize the pointer to this cache in its parent's memcg_params
> - * before adding it to the memcg_slab_caches list, otherwise we can
> - * fail to convert memcg_params_to_cache() while traversing the list.
> - */
> - VM_BUG_ON(root->memcg_params->memcg_caches[id]);
> - root->memcg_params->memcg_caches[id] = s;
> -
> - mutex_lock(&memcg->slab_caches_mutex);
> - list_add(&s->memcg_params->list, &memcg->memcg_slab_caches);
> - mutex_unlock(&memcg->slab_caches_mutex);
> + BUG_ON(root_cache->memcg_params->memcg_caches[id]);
> + root_cache->memcg_params->memcg_caches[id] = cachep;
> }
>
> -void memcg_unregister_cache(struct kmem_cache *s)
> +static void memcg_kmem_destroy_cache(struct kmem_cache *cachep)
memcg_destroy_kmem_cache()?
> @@ -3258,70 +3250,42 @@ static inline void memcg_resume_kmem_account(void)
> current->memcg_kmem_skip_account--;
> }
>
> -static void kmem_cache_destroy_work_func(struct work_struct *w)
> -{
> - struct kmem_cache *cachep;
> - struct memcg_cache_params *p;
> -
> - p = container_of(w, struct memcg_cache_params, destroy);
> -
> - cachep = memcg_params_to_cache(p);
> -
> - kmem_cache_shrink(cachep);
> - if (atomic_read(&cachep->memcg_params->nr_pages) == 0)
> - kmem_cache_destroy(cachep);
> -}
> -
> int __kmem_cache_destroy_memcg_children(struct kmem_cache *s)
kmem_cache_destroy_memcg_copies()?
> static void mem_cgroup_destroy_all_caches(struct mem_cgroup *memcg)
memcg_destroy_kmem_cache_copies()?
> @@ -266,22 +265,15 @@ EXPORT_SYMBOL(kmem_cache_create);
> * requests going from @memcg to @root_cache. The new cache inherits properties
> * from its parent.
> */
> -void kmem_cache_create_memcg(struct mem_cgroup *memcg, struct kmem_cache *root_cache)
> +struct kmem_cache *kmem_cache_create_memcg(struct mem_cgroup *memcg,
> + struct kmem_cache *root_cache)
kmem_cache_request_memcg_copy()?
> {
> - struct kmem_cache *s;
> + struct kmem_cache *s = NULL;
> char *cache_name;
>
> get_online_cpus();
> mutex_lock(&slab_mutex);
>
> - /*
> - * Since per-memcg caches are created asynchronously on first
> - * allocation (see memcg_kmem_get_cache()), several threads can try to
> - * create the same cache, but only one of them may succeed.
> - */
> - if (cache_from_memcg_idx(root_cache, memcg_cache_id(memcg)))
> - goto out_unlock;
> -
> cache_name = memcg_create_cache_name(memcg, root_cache);
memcg_name_kmem_cache()?
--
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-04-18 14:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-18 8:04 [PATCH RFC -mm v2 0/3] kmemcg: simplify work-flow (was "memcg-vs-slab cleanup") Vladimir Davydov
2014-04-18 8:04 ` [PATCH RFC -mm v2 1/3] memcg, slab: do not schedule cache destruction when last page goes away Vladimir Davydov
2014-04-18 13:41 ` Johannes Weiner
2014-04-18 16:05 ` Vladimir Davydov
2014-04-18 8:04 ` [PATCH RFC -mm v2 2/3] memcg, slab: merge memcg_{bind,release}_pages to memcg_{un}charge_slab Vladimir Davydov
2014-04-18 13:44 ` Johannes Weiner
2014-04-18 16:07 ` Vladimir Davydov
2014-04-18 8:04 ` [PATCH RFC -mm v2 3/3] memcg, slab: simplify synchronization scheme Vladimir Davydov
2014-04-18 14:17 ` Johannes Weiner [this message]
2014-04-18 16:08 ` Vladimir Davydov
2014-04-18 18:26 ` Johannes Weiner
2014-04-18 8:08 ` [PATCH RFC -mm v2 0/3] kmemcg: simplify work-flow (was "memcg-vs-slab cleanup") Vladimir Davydov
2014-04-18 13:23 ` Johannes Weiner
2014-04-18 16:04 ` Vladimir Davydov
2014-04-20 10:32 ` 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=20140418141734.GD26283@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--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=vdavydov@parallels.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