From: Andi Kleen <andi@firstfloor.org>
To: Richard Kennedy <richard@rsk.demon.co.uk>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] RFC SLUB: increase range of kmalloc slab sizes
Date: Sat, 13 Oct 2012 16:46:19 -0700 [thread overview]
Message-ID: <m2y5jarl4k.fsf@firstfloor.org> (raw)
In-Reply-To: <1350145885-6099-1-git-send-email-richard@rsk.demon.co.uk> (Richard Kennedy's message of "Sat, 13 Oct 2012 17:31:23 +0100")
Richard Kennedy <richard@rsk.demon.co.uk> writes:
> This patch increases the range of slab sizes available to kmalloc, adding
> slabs half way between the existing power of two sized ones, so allowing slightly
> more efficient use of memory.
> Most of the new slabs already exist as kmem_cache slabs so only the 1.5k,3k & 6k
> are entirely new.
I'm not sure what order slab/slub use by default these days, but for
order 0 none of your new sizes sound like a winner:
4K / 1.5 = 2 = 4K / 2K
4K / 3K = 1 = 4K / 4K
8K / 6K = 1 = 8K / 8K
I think you need better data that it actually saves memory with some
reproducible workloads.
Revisiting the sizes is a good idea -- the original Bonwick slab paper
explicitely recommended against power of twos -- but I think it needs a
more data driven process to actually select better ones than what you
used.
Most likely the best fits are different between 32bit and 64bit
and also will change occasionally as kernel data structures grow
(or rarely shrink)
In fact I suspect it would be an interesting option for feedback
control for embedded kernels - measure workload, reboot/recompile with
slab fitting the workload well.
So I think before trying any of this you need a good slab profiler
and a good set of workloads.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
--
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:[~2012-10-13 23:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-13 16:31 Richard Kennedy
2012-10-13 16:31 ` [PATCH 1/2] SLUB: remove hard coded magic numbers from resiliency_test Richard Kennedy
2012-10-13 16:31 ` [PATCH 2/2] SLUB: increase the range of slab sizes available to kmalloc, allowing a somewhat more effient use of memory Richard Kennedy
2012-10-15 20:44 ` Christoph Lameter
2012-10-15 20:41 ` [PATCH 1/2] SLUB: remove hard coded magic numbers from resiliency_test Christoph Lameter
2012-10-16 0:53 ` David Rientjes
2012-10-16 13:47 ` Christoph Lameter
2012-10-13 23:46 ` Andi Kleen [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=m2y5jarl4k.fsf@firstfloor.org \
--to=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=richard@rsk.demon.co.uk \
/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