From: Mel Gorman <mel@csn.ul.ie>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Nick Piggin <npiggin@suse.de>,
heiko.carstens@de.ibm.com, sachinp@in.ibm.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Tejun Heo <tj@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH 2/4] slqb: Record what node is local to a kmem_cache_cpu
Date: Thu, 1 Oct 2009 16:16:57 +0100 [thread overview]
Message-ID: <20091001151657.GH21906@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.1.10.0910011101390.3911@gentwo.org>
On Thu, Oct 01, 2009 at 11:03:16AM -0400, Christoph Lameter wrote:
> On Thu, 1 Oct 2009, Mel Gorman wrote:
>
> > True, it might have been improved more if SLUB knew what local hugepage it
> > resided within as the kernel portion of the address space is backed by huge
> > TLB entries. Note that SLQB could have an advantage here early in boot as
> > the page allocator will tend to give it back pages within a single huge TLB
> > entry. It loses the advantage when the system has been running for a very long
> > time but it might be enough to skew benchmark results on cold-booted systems.
>
> The page allocator serves pages aligned to huge page boundaries as far as
> I can remember.
You're right, it does, particularly early in boot. It loses the advantage
when the system has been running a long time and memory is mostly full but
the same will apply to SLQB.
> You can actually use huge pages in slub if you set the max
> order to 9. So a page obtained from the page allocator is always aligned
> properly.
>
Fair point.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Nick Piggin <npiggin@suse.de>,
heiko.carstens@de.ibm.com, sachinp@in.ibm.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Tejun Heo <tj@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH 2/4] slqb: Record what node is local to a kmem_cache_cpu
Date: Thu, 1 Oct 2009 16:16:57 +0100 [thread overview]
Message-ID: <20091001151657.GH21906@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.1.10.0910011101390.3911@gentwo.org>
On Thu, Oct 01, 2009 at 11:03:16AM -0400, Christoph Lameter wrote:
> On Thu, 1 Oct 2009, Mel Gorman wrote:
>
> > True, it might have been improved more if SLUB knew what local hugepage it
> > resided within as the kernel portion of the address space is backed by huge
> > TLB entries. Note that SLQB could have an advantage here early in boot as
> > the page allocator will tend to give it back pages within a single huge TLB
> > entry. It loses the advantage when the system has been running for a very long
> > time but it might be enough to skew benchmark results on cold-booted systems.
>
> The page allocator serves pages aligned to huge page boundaries as far as
> I can remember.
You're right, it does, particularly early in boot. It loses the advantage
when the system has been running a long time and memory is mostly full but
the same will apply to SLQB.
> You can actually use huge pages in slub if you set the max
> order to 9. So a page obtained from the page allocator is always aligned
> properly.
>
Fair point.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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-10-01 15:16 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 12:54 [PATCH 0/3] Fix SLQB on memoryless configurations V3 Mel Gorman
2009-09-22 12:54 ` Mel Gorman
2009-09-22 12:54 ` [PATCH 1/4] slqb: Do not use DEFINE_PER_CPU for per-node data Mel Gorman
2009-09-22 12:54 ` Mel Gorman
2009-09-22 18:55 ` Pekka Enberg
2009-09-22 18:55 ` Pekka Enberg
2009-09-22 12:54 ` [PATCH 2/4] slqb: Record what node is local to a kmem_cache_cpu Mel Gorman
2009-09-22 12:54 ` Mel Gorman
2009-09-22 13:38 ` Pekka Enberg
2009-09-22 13:38 ` Pekka Enberg
2009-09-22 13:54 ` Mel Gorman
2009-09-22 13:54 ` Mel Gorman
2009-09-22 18:54 ` Pekka Enberg
2009-09-22 18:54 ` Pekka Enberg
2009-09-22 18:56 ` Mel Gorman
2009-09-22 18:56 ` Mel Gorman
2009-09-30 14:41 ` Mel Gorman
2009-09-30 14:41 ` Mel Gorman
2009-09-30 15:06 ` Christoph Lameter
2009-09-30 15:06 ` Christoph Lameter
2009-09-30 22:05 ` Mel Gorman
2009-09-30 22:05 ` Mel Gorman
2009-09-30 23:45 ` Christoph Lameter
2009-09-30 23:45 ` Christoph Lameter
2009-10-01 10:40 ` Mel Gorman
2009-10-01 10:40 ` Mel Gorman
2009-10-01 14:32 ` Christoph Lameter
2009-10-01 14:32 ` Christoph Lameter
2009-10-01 15:03 ` Mel Gorman
2009-10-01 15:03 ` Mel Gorman
2009-10-01 15:03 ` Christoph Lameter
2009-10-01 15:03 ` Christoph Lameter
2009-10-01 15:16 ` Mel Gorman [this message]
2009-10-01 15:16 ` Mel Gorman
2009-10-04 12:06 ` Pekka Enberg
2009-10-04 12:06 ` Pekka Enberg
2009-10-05 9:49 ` Mel Gorman
2009-10-05 9:49 ` Mel Gorman
2009-09-22 12:54 ` [PATCH 3/4] slqb: Allow SLQB to be used on PPC and S390 Mel Gorman
2009-09-22 12:54 ` Mel Gorman
2009-09-22 13:21 ` [PATCH 0/3] Fix SLQB on memoryless configurations V3 Mel Gorman
2009-09-22 13:21 ` Mel Gorman
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=20091001151657.GH21906@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=benh@kernel.crashing.org \
--cc=cl@linux-foundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=penberg@cs.helsinki.fi \
--cc=sachinp@in.ibm.com \
--cc=tj@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.