All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Christoph Lameter <cl@linux.com>
Subject: Re: [PATCH 1/2] memcg: move memcg_{alloc,free}_cache_params to slab_common.c
Date: Mon, 22 Sep 2014 16:51:15 +0200	[thread overview]
Message-ID: <20140922145115.GI336@dhcp22.suse.cz> (raw)
In-Reply-To: <20140922141420.GD18526@esperanza>

On Mon 22-09-14 18:14:20, Vladimir Davydov wrote:
> On Mon, Sep 22, 2014 at 03:52:45PM +0200, Michal Hocko wrote:
> > On Thu 18-09-14 19:50:19, Vladimir Davydov wrote:
> > > The only reason why they live in memcontrol.c is that we get/put css
> > > reference to the owner memory cgroup in them. However, we can do that in
> > > memcg_{un,}register_cache.
> > > 
> > > So let's move them to slab_common.c and make them static.
> > 
> > Why is it better?
> 
> First, I think that the less public interface functions we have in
> memcontrol.h the better. Since the functions I move don't depend on
> memcontrol, I think it's worth making them private to slab, especially
> taking into account that the arrays are defined on the slab's side too.
> 
> Second, the way how per-memcg arrays are updated looks rather awkward:
> it proceeds from memcontrol.c (__memcg_activate_kmem) to slab_common.c
> (memcg_update_all_caches) and back to memcontrol.c again
> (memcg_update_array_size). In the next patch I move the function
> relocating the arrays (memcg_update_array_size) to slab_common.c and
> therefore get rid this circular call path. I think we should have the
> cache allocation stuff in the same place where we have relocation,
> because it's easier to follow the code then. So I move arrays alloc/free
> functions to slab_common.c too.
> 
> The third point isn't obvious. In the "Per memcg slab shrinkers" patch
> set, which I sent recently, I have to update per-memcg list_lrus arrays
> too. And it's much easier and cleaner to do it in list_lru.c rather than
> in memcontrol.c. The current patchset makes cache arrays allocation path
> conform that of the upcoming list_lru.

Exactly what I would love to have in the changelog...

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

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Christoph Lameter <cl@linux.com>
Subject: Re: [PATCH 1/2] memcg: move memcg_{alloc,free}_cache_params to slab_common.c
Date: Mon, 22 Sep 2014 16:51:15 +0200	[thread overview]
Message-ID: <20140922145115.GI336@dhcp22.suse.cz> (raw)
In-Reply-To: <20140922141420.GD18526@esperanza>

On Mon 22-09-14 18:14:20, Vladimir Davydov wrote:
> On Mon, Sep 22, 2014 at 03:52:45PM +0200, Michal Hocko wrote:
> > On Thu 18-09-14 19:50:19, Vladimir Davydov wrote:
> > > The only reason why they live in memcontrol.c is that we get/put css
> > > reference to the owner memory cgroup in them. However, we can do that in
> > > memcg_{un,}register_cache.
> > > 
> > > So let's move them to slab_common.c and make them static.
> > 
> > Why is it better?
> 
> First, I think that the less public interface functions we have in
> memcontrol.h the better. Since the functions I move don't depend on
> memcontrol, I think it's worth making them private to slab, especially
> taking into account that the arrays are defined on the slab's side too.
> 
> Second, the way how per-memcg arrays are updated looks rather awkward:
> it proceeds from memcontrol.c (__memcg_activate_kmem) to slab_common.c
> (memcg_update_all_caches) and back to memcontrol.c again
> (memcg_update_array_size). In the next patch I move the function
> relocating the arrays (memcg_update_array_size) to slab_common.c and
> therefore get rid this circular call path. I think we should have the
> cache allocation stuff in the same place where we have relocation,
> because it's easier to follow the code then. So I move arrays alloc/free
> functions to slab_common.c too.
> 
> The third point isn't obvious. In the "Per memcg slab shrinkers" patch
> set, which I sent recently, I have to update per-memcg list_lrus arrays
> too. And it's much easier and cleaner to do it in list_lru.c rather than
> in memcontrol.c. The current patchset makes cache arrays allocation path
> conform that of the upcoming list_lru.

Exactly what I would love to have in the changelog...

Thanks!
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2014-09-22 14:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 15:50 [PATCH 1/2] memcg: move memcg_{alloc,free}_cache_params to slab_common.c Vladimir Davydov
2014-09-18 15:50 ` Vladimir Davydov
2014-09-18 15:50 ` [PATCH 2/2] memcg: move memcg_update_cache_size " Vladimir Davydov
2014-09-18 15:50   ` Vladimir Davydov
2014-09-22 14:07   ` Michal Hocko
2014-09-22 14:07     ` Michal Hocko
2014-09-22 14:20     ` Vladimir Davydov
2014-09-22 14:20       ` Vladimir Davydov
2014-09-22 14:49       ` Michal Hocko
2014-09-22 14:49         ` Michal Hocko
2014-09-22 20:11   ` Johannes Weiner
2014-09-22 20:11     ` Johannes Weiner
2014-09-23  7:26     ` Vladimir Davydov
2014-09-23  7:26       ` Vladimir Davydov
2014-09-22 13:52 ` [PATCH 1/2] memcg: move memcg_{alloc,free}_cache_params " Michal Hocko
2014-09-22 13:52   ` Michal Hocko
2014-09-22 14:14   ` Vladimir Davydov
2014-09-22 14:14     ` Vladimir Davydov
2014-09-22 14:51     ` Michal Hocko [this message]
2014-09-22 14:51       ` Michal Hocko
2014-09-22 20:08 ` Johannes Weiner
2014-09-22 20:08   ` Johannes Weiner
2014-09-23  7:31   ` Vladimir Davydov
2014-09-23  7:31     ` 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=20140922145115.GI336@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.