linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Christoph Lameter <cl@linux.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 3/3] memcg: move memcg_update_cache_size to slab_common.c
Date: Tue, 23 Sep 2014 20:09:20 +0200	[thread overview]
Message-ID: <20140923180920.GC29528@dhcp22.suse.cz> (raw)
In-Reply-To: <dd66241915c99132e41f10d0cd0d346be3a4f39c.1411401021.git.vdavydov@parallels.com>

On Mon 22-09-14 20:00:46, Vladimir Davydov wrote:
> While growing per memcg caches arrays, we jump between memcontrol.c and
> slab_common.c in a weird way:
> 
>   memcg_alloc_cache_id - memcontrol.c
>     memcg_update_all_caches - slab_common.c
>       memcg_update_cache_size - memcontrol.c
> 
> There's absolutely no reason why memcg_update_cache_size can't live on
> the slab's side though. So let's move it there and settle it comfortably
> amid per-memcg cache allocation functions.
> 
> Besides, this patch cleans this function up a bit, removing all the
> useless comments from it, and renames it to memcg_update_cache_params to
> conform to memcg_alloc/free_cache_params, which we already have in
> slab_common.c.
> 
> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>

I found new_params->memcg_caches[i] = ... style of initialization easier
to read and understand than memcpy. This is not something to block
this cleanup but I would be happier to have the array style back ;)

Acked-by: Michal Hocko <mhocko@suse.cz>

> ---
>  include/linux/memcontrol.h |    1 -
>  mm/memcontrol.c            |   49 --------------------------------------------
>  mm/slab_common.c           |   30 +++++++++++++++++++++++++--
>  3 files changed, 28 insertions(+), 52 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 4d17242eeff7..19df5d857411 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -440,7 +440,6 @@ void __memcg_kmem_uncharge_pages(struct page *page, int order);
>  
>  int memcg_cache_id(struct mem_cgroup *memcg);
>  
> -int memcg_update_cache_size(struct kmem_cache *s, int num_groups);
>  void memcg_update_array_size(int num_groups);
>  
>  struct kmem_cache *
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 55d131645b45..1ec22bf380d0 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2944,55 +2944,6 @@ void memcg_update_array_size(int num)
>  	memcg_limited_groups_array_size = num;
>  }
>  
> -int memcg_update_cache_size(struct kmem_cache *s, int num_groups)
> -{
> -	struct memcg_cache_params *cur_params = s->memcg_params;
> -	struct memcg_cache_params *new_params;
> -	size_t size;
> -	int i;
> -
> -	VM_BUG_ON(!is_root_cache(s));
> -
> -	size = num_groups * sizeof(void *);
> -	size += offsetof(struct memcg_cache_params, memcg_caches);
> -
> -	new_params = kzalloc(size, GFP_KERNEL);
> -	if (!new_params)
> -		return -ENOMEM;
> -
> -	new_params->is_root_cache = true;
> -
> -	/*
> -	 * There is the chance it will be bigger than
> -	 * memcg_limited_groups_array_size, if we failed an allocation
> -	 * in a cache, in which case all caches updated before it, will
> -	 * have a bigger array.
> -	 *
> -	 * But if that is the case, the data after
> -	 * memcg_limited_groups_array_size is certainly unused
> -	 */
> -	for (i = 0; i < memcg_limited_groups_array_size; i++) {
> -		if (!cur_params->memcg_caches[i])
> -			continue;
> -		new_params->memcg_caches[i] =
> -			cur_params->memcg_caches[i];
> -	}
> -
> -	/*
> -	 * Ideally, we would wait until all caches succeed, and only
> -	 * then free the old one. But this is not worth the extra
> -	 * pointer per-cache we'd have to have for this.
> -	 *
> -	 * It is not a big deal if some caches are left with a size
> -	 * bigger than the others. And all updates will reset this
> -	 * anyway.
> -	 */
> -	rcu_assign_pointer(s->memcg_params, new_params);
> -	if (cur_params)
> -		kfree_rcu(cur_params, rcu_head);
> -	return 0;
> -}
> -
>  static void memcg_register_cache(struct mem_cgroup *memcg,
>  				 struct kmem_cache *root_cache)
>  {
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 9c29ba792368..800314e2a075 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -120,6 +120,33 @@ static void memcg_free_cache_params(struct kmem_cache *s)
>  	kfree(s->memcg_params);
>  }
>  
> +static int memcg_update_cache_params(struct kmem_cache *s, int num_memcgs)
> +{
> +	int size;
> +	struct memcg_cache_params *new_params, *cur_params;
> +
> +	BUG_ON(!is_root_cache(s));
> +
> +	size = offsetof(struct memcg_cache_params, memcg_caches);
> +	size += num_memcgs * sizeof(void *);
> +
> +	new_params = kzalloc(size, GFP_KERNEL);
> +	if (!new_params)
> +		return -ENOMEM;
> +
> +	cur_params = s->memcg_params;
> +	memcpy(new_params->memcg_caches, cur_params->memcg_caches,
> +	       memcg_limited_groups_array_size * sizeof(void *));
> +
> +	new_params->is_root_cache = true;
> +
> +	rcu_assign_pointer(s->memcg_params, new_params);
> +	if (cur_params)
> +		kfree_rcu(cur_params, rcu_head);
> +
> +	return 0;
> +}
> +
>  int memcg_update_all_caches(int num_memcgs)
>  {
>  	struct kmem_cache *s;
> @@ -130,9 +157,8 @@ int memcg_update_all_caches(int num_memcgs)
>  		if (!is_root_cache(s))
>  			continue;
>  
> -		ret = memcg_update_cache_size(s, num_memcgs);
> +		ret = memcg_update_cache_params(s, num_memcgs);
>  		/*
> -		 * See comment in memcontrol.c, memcg_update_cache_size:
>  		 * Instead of freeing the memory, we'll just leave the caches
>  		 * up to this point in an updated state.
>  		 */
> -- 
> 1.7.10.4
> 

-- 
Michal Hocko
SUSE Labs

--
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>

      reply	other threads:[~2014-09-23 18:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-22 16:00 [PATCH v2 0/3] memcg: trivial cleanups in kmemcg core Vladimir Davydov
2014-09-22 16:00 ` [PATCH v2 1/3] memcg: move memcg_{alloc,free}_cache_params to slab_common.c Vladimir Davydov
2014-09-23 17:40   ` Michal Hocko
2014-09-22 16:00 ` [PATCH v2 2/3] memcg: don't call memcg_update_all_caches if new cache id fits Vladimir Davydov
2014-09-23 18:00   ` Michal Hocko
2014-09-22 16:00 ` [PATCH v2 3/3] memcg: move memcg_update_cache_size to slab_common.c Vladimir Davydov
2014-09-23 18:09   ` Michal Hocko [this message]

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=20140923180920.GC29528@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).