From: Vladimir Davydov <vdavydov@parallels.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>, Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 8/8] slab: recharge slab pages to the allocating memory cgroup
Date: Thu, 6 Nov 2014 18:22:09 +0300 [thread overview]
Message-ID: <20141106152209.GF4839@esperanza> (raw)
In-Reply-To: <alpine.DEB.2.11.1411060858530.4639@gentwo.org>
On Thu, Nov 06, 2014 at 09:01:52AM -0600, Christoph Lameter wrote:
> On Thu, 6 Nov 2014, Vladimir Davydov wrote:
>
> > I call memcg_kmem_recharge_slab only on alloc path. Free path isn't
> > touched. The overhead added is one function call. The function only
> > reads and compares two pointers under RCU most of time. This is
> > comparable to the overhead introduced by memcg_kmem_get_cache, which is
> > called in slab_alloc/slab_alloc_node earlier.
>
> Right maybe remove those too? Things seem to be accumulating in the hot
> path which is bad. There is a slow path where these things can be added
> and also a page based even slower path for statistics keeping.
>
> The approach in SLUB is to do accounting on a slab page basis. Also memory
> policies are applied at page granularity not object granularity.
>
> > Anyways, if you think this is unacceptable, I don't mind dropping the
> > whole patch set and thinking more on how to fix this per-memcg caches
> > trickery. What do you think?
>
> Maybe its possible to just use slab page accounting instead of object
> accounting? Reduces overhead significantly. There may be some fuzz here
> with occasional object accounted in the wrong way (which is similar to how
> memory policies and other methods work) but it has been done before and
> works ok.
Actually, it's not about mis-accounting. The problem is a newly
allocated object can pin a charge of a dead cgroup that used the cache
before. May be, it wouldn't be a problem though.
Anyways, I think I need more time to brood over the whole approach, so
I've asked Andrew to drop the patch set.
Thank you for the feedback!
--
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>
prev parent reply other threads:[~2014-11-06 15:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 20:59 [PATCH -mm 0/8] memcg: reuse per cgroup kmem caches Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 1/8] memcg: do not destroy kmem caches on css offline Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 2/8] slab: charge slab pages to the current memory cgroup Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 3/8] memcg: decouple per memcg kmem cache from the owner memcg Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 4/8] memcg: zap memcg_{un}register_cache Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 5/8] memcg: free kmem cache id on css offline Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 6/8] memcg: introduce memcg_kmem_should_charge helper Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 7/8] slab: introduce slab_free helper Vladimir Davydov
2014-11-05 18:42 ` Christoph Lameter
2014-11-06 10:59 ` Vladimir Davydov
2014-11-03 20:59 ` [PATCH -mm 8/8] slab: recharge slab pages to the allocating memory cgroup Vladimir Davydov
2014-11-05 18:43 ` Christoph Lameter
2014-11-06 9:17 ` Vladimir Davydov
2014-11-06 15:01 ` Christoph Lameter
2014-11-06 15:22 ` Vladimir Davydov [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=20141106152209.GF4839@esperanza \
--to=vdavydov@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.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;
as well as URLs for NNTP newsgroup(s).