From: Pekka Enberg <penberg@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <cl@linux.com>,
Mike Snitzer <snitzer@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Heinz Mauelshagen <heinzm@redhat.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Dave Chinner <dchinner@redhat.com>, Joe Thornber <ejt@redhat.com>,
linux-mm <linux-mm@kvack.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Sami Tolvanen <samitolvanen@google.com>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Alasdair G Kergon <agk@redhat.com>
Subject: Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
Date: Thu, 3 Sep 2015 09:09:24 +0300 [thread overview]
Message-ID: <CAOJsxLGa9fLWUrdjnm-A-Frxr1bzBvfNZRsmFFcjQSvGX48a4w@mail.gmail.com> (raw)
In-Reply-To: <20150902215512.9d0d62e74fa2f0a460a42af9@linux-foundation.org>
Hi Andrew,
On Wed, 2 Sep 2015 22:10:12 -0500 (CDT) Christoph Lameter <cl@linux.com> wrote:
>> > But I'd still like some pointers/help on what makes slab merging so
>> > beneficial. I'm sure Christoph and others have justification. But if
>> > not then yes the default to slab merging probably should be revisited.
>>
>> ...
>>
>> Check out the linux-mm archives for these dissussions.
On Thu, Sep 3, 2015 at 7:55 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> Somewhat OT, but... The question Mike asks should be comprehensively
> answered right there in the switch-to-merging patch's changelog.
>
> The fact that it is not answered in the appropriate place and that
> we're reduced to vaguely waving at the list archives is a fail. And a
> lesson!
Slab merging is a technique to reduce memory footprint and memory
fragmentation. Joonsoo reports 3% slab memory reduction after boot
when he added the feature to SLAB:
commit 12220dea07f1ac6ac717707104773d771c3f3077
Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Date: Thu Oct 9 15:26:24 2014 -0700
mm/slab: support slab merge
Slab merge is good feature to reduce fragmentation. If new creating slab
have similar size and property with exsitent slab, this feature reuse it
rather than creating new one. As a result, objects are packed into fewer
slabs so that fragmentation is reduced.
Below is result of my testing.
* After boot, sleep 20; cat /proc/meminfo | grep Slab
<Before>
Slab: 25136 kB
<After>
Slab: 24364 kB
We can save 3% memory used by slab.
For supporting this feature in SLAB, we need to implement SLAB specific
kmem_cache_flag() and __kmem_cache_alias(), because SLUB implements some
SLUB specific processing related to debug flag and object size change on
these functions.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We don't have benchmarks to directly measure its performance impact
but you should see its effect via something like netperf that stresses
the allocator heavily. The assumed benefit is that you're able to
recycle cache hot objects much more efficiently as SKB cache and
friends are merged to regular kmalloc caches.
In any case, reducing kernel memory footprint already is a big win for
various use cases, so keeping slab merging on by default is desirable.
- Pekka
--
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:[~2015-09-03 6:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 23:13 slab-nomerge (was Re: [git pull] device mapper changes for 4.3) Linus Torvalds
2015-09-03 0:48 ` Andrew Morton
2015-09-03 0:53 ` Mike Snitzer
2015-09-03 0:51 ` Mike Snitzer
2015-09-03 1:21 ` Linus Torvalds
2015-09-03 2:31 ` Mike Snitzer
2015-09-03 3:10 ` Christoph Lameter
2015-09-03 4:55 ` Andrew Morton
2015-09-03 6:09 ` Pekka Enberg [this message]
2015-09-03 8:53 ` Dave Chinner
2015-09-03 3:11 ` Linus Torvalds
2015-09-03 6:02 ` Dave Chinner
2015-09-03 6:13 ` Pekka Enberg
2015-09-03 10:29 ` Jesper Dangaard Brouer
2015-09-03 16:19 ` Christoph Lameter
2015-09-04 9:10 ` Jesper Dangaard Brouer
2015-09-04 14:13 ` Christoph Lameter
2015-09-04 6:35 ` Sergey Senozhatsky
2015-09-04 7:01 ` Linus Torvalds
2015-09-04 7:59 ` Sergey Senozhatsky
2015-09-04 9:56 ` Sergey Senozhatsky
2015-09-04 14:05 ` Christoph Lameter
2015-09-04 14:11 ` Linus Torvalds
2015-09-05 2:09 ` Sergey Senozhatsky
2015-09-05 20:33 ` Linus Torvalds
2015-09-07 8:44 ` Sergey Senozhatsky
2015-09-08 0:22 ` Sergey Senozhatsky
2015-09-03 15:02 ` Linus Torvalds
2015-09-04 3:26 ` Dave Chinner
2015-09-04 3:51 ` Linus Torvalds
2015-09-05 0:36 ` Dave Chinner
2015-09-07 9:30 ` Jesper Dangaard Brouer
2015-09-07 20:22 ` Linus Torvalds
2015-09-07 21:17 ` Jesper Dangaard Brouer
2015-09-04 13:55 ` Christoph Lameter
2015-09-04 22:46 ` Dave Chinner
2015-09-05 0:25 ` Christoph Lameter
2015-09-05 1:16 ` Dave Chinner
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=CAOJsxLGa9fLWUrdjnm-A-Frxr1bzBvfNZRsmFFcjQSvGX48a4w@mail.gmail.com \
--to=penberg@kernel.org \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dchinner@redhat.com \
--cc=dm-devel@redhat.com \
--cc=ejt@redhat.com \
--cc=heinzm@redhat.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=mpatocka@redhat.com \
--cc=rientjes@google.com \
--cc=samitolvanen@google.com \
--cc=snitzer@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.com \
--cc=viresh.kumar@linaro.org \
/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).