From: Vladimir Davydov <vdavydov@parallels.com>
To: akpm@linux-foundation.org
Cc: cl@linux.com, hannes@cmpxchg.org, mhocko@suse.cz,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: [PATCH -mm 0/8] memcg/slab: reintroduce dead cache self-destruction
Date: Fri, 30 May 2014 17:51:03 +0400 [thread overview]
Message-ID: <cover.1401457502.git.vdavydov@parallels.com> (raw)
Hi,
When a memcg is turned offline, some of its kmem caches can still have
active objects and therefore cannot be destroyed immediately. Currently,
we simply leak such caches along with the owner memcg, which is bad and
should be resolved.
It would be perfect if we could move all slab pages of such dead caches
to the root/parent cache on memcg offline. However, when I tried to
implement such re-parenting, I was pointed out by Christoph that the
overhead of this would be unacceptable, at least for SLUB (see
https://lkml.org/lkml/2014/5/13/446)
The problem with re-parenting of individual slabs is that it requires
tracking of all slabs allocated to a cache, but SLUB doesn't track full
slabs if !debug. Changing this behavior would result in significant
performance degradation of regular alloc/free paths, because it would
make alloc/free take per node list locks more often.
After pondering about this problem for some time, I think we should
return to dead caches self-destruction, i.e. scheduling cache
destruction work when the last slab page is freed.
This is the behavior we had before commit 5bd93da9917f ("memcg, slab:
simplify synchronization scheme"). The reason why it was removed was that
it simply didn't work, because SL[AU]B are implemented in such a way
that they don't discard empty slabs immediately, but prefer keeping them
cached for indefinite time to speed up further allocations.
However, we can change this w/o noticeable performance impact for both
SLAB and SLUB. For SLAB, we can make internal cache reaper shrink dead
caches aggressively so that they will die quickly after the last object
is freed. For SLUB, we can make free path drop free slabs as soon as
they become empty. Since dead caches should never be allocated from,
removing empty slabs from them shouldn't degrade performance.
So, this patch set reintroduces dead cache self-destruction and adds
some tweaks to SL[AU]B to prevent dead caches from hanging around
indefinitely. It is organized as follows:
- patches 1-3 reintroduce dead memcg cache self-destruction;
- patches 4-5 do some cleanup in kmem_cache_shrink;
- patch 6 is a minor optimization for SLUB, which makes the following
work a bit easier for me;
- patches 7 and 8 solves the problem with dead memcg caches for SLUB
and SLAB respectively.
Even if the whole approach is NAK'ed, patches 4, 5, and 6 are worth
applying, IMO, provided Christoph doesn't mind, of course. They don't
depend on the rest of the set, BTW.
Note, this doesn't resolve the problem of memcgs pinned by dead kmem
caches. I'm planning to solve this by re-parenting dead kmem caches to
the parent memcg.
Thanks,
Vladimir Davydov (8):
memcg: cleanup memcg_cache_params refcnt usage
memcg: destroy kmem caches when last slab is freed
memcg: mark caches that belong to offline memcgs as dead
slub: never fail kmem_cache_shrink
slab: remove kmem_cache_shrink retval
slub: do not use cmpxchg for adding cpu partials when irqs disabled
slub: make dead caches discard free slabs immediately
slab: reap dead memcg caches aggressively
include/linux/slab.h | 10 ++-
mm/memcontrol.c | 25 +++++-
mm/slab.c | 28 +++++--
mm/slab.h | 12 ++-
mm/slab_common.c | 8 +-
mm/slob.c | 3 +-
mm/slub.c | 212 ++++++++++++++++++++++++++++++++++----------------
7 files changed, 207 insertions(+), 91 deletions(-)
--
1.7.10.4
--
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 reply other threads:[~2014-05-30 13:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 13:51 Vladimir Davydov [this message]
2014-05-30 13:51 ` [PATCH -mm 1/8] memcg: cleanup memcg_cache_params refcnt usage Vladimir Davydov
2014-05-30 14:31 ` Christoph Lameter
2014-05-30 13:51 ` [PATCH -mm 2/8] memcg: destroy kmem caches when last slab is freed Vladimir Davydov
2014-05-30 14:32 ` Christoph Lameter
2014-05-30 13:51 ` [PATCH -mm 3/8] memcg: mark caches that belong to offline memcgs as dead Vladimir Davydov
2014-05-30 14:33 ` Christoph Lameter
2014-05-30 13:51 ` [PATCH -mm 4/8] slub: never fail kmem_cache_shrink Vladimir Davydov
2014-05-30 14:46 ` Christoph Lameter
2014-05-31 10:18 ` Vladimir Davydov
2014-06-02 15:13 ` Christoph Lameter
2014-05-30 13:51 ` [PATCH -mm 5/8] slab: remove kmem_cache_shrink retval Vladimir Davydov
2014-05-30 14:49 ` Christoph Lameter
2014-05-31 10:27 ` Vladimir Davydov
2014-06-02 15:16 ` Christoph Lameter
2014-06-03 9:06 ` Vladimir Davydov
2014-06-03 14:48 ` Christoph Lameter
2014-06-03 19:00 ` Vladimir Davydov
2014-05-30 13:51 ` [PATCH -mm 6/8] slub: do not use cmpxchg for adding cpu partials when irqs disabled Vladimir Davydov
2014-05-30 13:51 ` [PATCH -mm 7/8] slub: make dead caches discard free slabs immediately Vladimir Davydov
2014-05-30 14:57 ` Christoph Lameter
2014-05-31 11:04 ` Vladimir Davydov
2014-06-02 4:24 ` Joonsoo Kim
2014-06-02 11:47 ` Vladimir Davydov
2014-06-02 14:03 ` Joonsoo Kim
2014-06-02 15:17 ` Christoph Lameter
2014-06-03 8:16 ` Vladimir Davydov
2014-06-04 8:53 ` Joonsoo Kim
2014-06-04 9:47 ` Vladimir Davydov
2014-05-30 13:51 ` [PATCH -mm 8/8] slab: reap dead memcg caches aggressively Vladimir Davydov
2014-05-30 15:01 ` Christoph Lameter
2014-05-31 11:19 ` Vladimir Davydov
2014-06-02 15:24 ` Christoph Lameter
2014-06-03 20:18 ` Vladimir Davydov
2014-06-02 4:41 ` Joonsoo Kim
2014-06-02 12:10 ` Vladimir Davydov
2014-06-02 14:01 ` Joonsoo Kim
2014-06-03 8:21 ` 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=cover.1401457502.git.vdavydov@parallels.com \
--to=vdavydov@parallels.com \
--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=mhocko@suse.cz \
/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).