From: Pekka Enberg <penberg@cs.helsinki.fi>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mel@csn.ul.ie>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Nick Piggin <npiggin@suse.de>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Lin Ming <ming.m.lin@intel.com>,
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Subject: Re: [patch] SLQB slab allocator (try 2)
Date: Wed, 18 Feb 2009 10:09:29 +0200 [thread overview]
Message-ID: <1234944569.24030.20.camel@penberg-laptop> (raw)
In-Reply-To: <20090218093858.8990.A69D9226@jp.fujitsu.com>
Hi!
On Wed, 2009-02-18 at 09:48 +0900, KOSAKI Motohiro wrote:
> I think 2 * PAGE_SIZE is best and the patch description is needed change.
> it's because almost architecture use two pages for stack and current page
> allocator don't have delayed consolidation mechanism for order-1 page.
Do you mean alloc_thread_info()? Not all architectures use kmalloc() to
implement it so I'm not sure if that's relevant for this patch.
On Wed, 2009-02-18 at 09:48 +0900, KOSAKI Motohiro wrote:
> In addition, if pekka patch (SLAB_LIMIT = 8K) run on ia64, 16K allocation
> always fallback to page allocator and using 64K (4 times memory consumption!).
Yes, correct, but SLUB does that already by passing all allocations over
4K to the page allocator.
I'm not totally against 2 * PAGE_SIZE but I just worry that as SLUB
performance will be bound to architecture page size, we will see skewed
results in performance tests without realizing it. That's why I'm in
favor of a fixed size that's unified across architectures.
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:[~2009-02-18 8:09 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-23 15:46 Nick Piggin
2009-01-24 2:38 ` Zhang, Yanmin
2009-01-26 8:48 ` Pekka Enberg
2009-01-26 9:07 ` Peter Zijlstra
2009-01-26 9:10 ` Peter Zijlstra
2009-01-26 17:22 ` Christoph Lameter
2009-01-27 9:07 ` Peter Zijlstra
2009-01-27 20:21 ` Christoph Lameter
2009-02-03 2:04 ` Nick Piggin
2009-02-03 10:12 ` Mel Gorman
2009-02-03 10:36 ` Nick Piggin
2009-02-03 11:22 ` Mel Gorman
2009-02-03 11:26 ` Mel Gorman
2009-02-04 6:48 ` Nick Piggin
2009-02-04 15:27 ` Mel Gorman
2009-02-05 3:59 ` Nick Piggin
2009-02-05 13:49 ` Mel Gorman
2009-02-16 18:42 ` Mel Gorman
2009-02-16 19:17 ` Pekka Enberg
2009-02-16 19:41 ` Mel Gorman
2009-02-16 19:43 ` Pekka Enberg
2009-02-17 1:06 ` Zhang, Yanmin
2009-02-17 16:20 ` Christoph Lameter
2009-02-17 17:01 ` Pekka Enberg
2009-02-17 17:05 ` Christoph Lameter
2009-02-17 17:24 ` Pekka Enberg
2009-02-17 18:11 ` Johannes Weiner
2009-02-17 19:43 ` Pekka Enberg
2009-02-17 20:04 ` Christoph Lameter
2009-02-18 0:48 ` KOSAKI Motohiro
2009-02-18 8:09 ` Pekka Enberg [this message]
2009-02-19 0:05 ` KOSAKI Motohiro
2009-02-19 9:16 ` Pekka Enberg
2009-02-19 12:51 ` KOSAKI Motohiro
2009-02-19 13:15 ` Pekka Enberg
2009-02-19 13:49 ` KOSAKI Motohiro
2009-02-19 14:19 ` Christoph Lameter
2009-02-18 1:05 ` Zhang, Yanmin
2009-02-18 7:48 ` Pekka Enberg
2009-02-18 8:43 ` Zhang, Yanmin
2009-02-18 9:01 ` Pekka Enberg
2009-02-18 9:19 ` Zhang, Yanmin
2009-02-19 8:40 ` Pekka Enberg
2009-02-16 19:25 ` Pekka Enberg
2009-02-16 19:44 ` Mel Gorman
2009-02-16 19:42 ` Pekka Enberg
2009-02-03 11:28 ` Mel Gorman
2009-02-03 11:50 ` Nick Piggin
2009-02-03 12:01 ` Mel Gorman
2009-02-03 12:07 ` Nick Piggin
2009-02-03 12:26 ` Mel Gorman
2009-02-04 15:49 ` Christoph Lameter
2009-02-04 15:48 ` Christoph Lameter
2009-02-03 18:58 ` Pekka Enberg
2009-02-04 16:06 ` Christoph Lameter
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=1234944569.24030.20.camel@penberg-laptop \
--to=penberg@cs.helsinki.fi \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=ming.m.lin@intel.com \
--cc=nickpiggin@yahoo.com.au \
--cc=npiggin@suse.de \
--cc=yanmin_zhang@linux.intel.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