linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Brent Casavant <bcasavan@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH 0/3] NUMA boot hash allocation interleaving
Date: Wed, 15 Dec 2004 12:24:10 -0600	[thread overview]
Message-ID: <Pine.SGI.4.61.0412151051270.24052@kzerza.americas.sgi.com> (raw)
In-Reply-To: <20041215071734.GO27225@wotan.suse.de>

On Wed, 15 Dec 2004, Andi Kleen wrote:

> On Tue, Dec 14, 2004 at 11:14:46PM -0800, Martin J. Bligh wrote:
> > Well hold on a sec. We don't need to use the hugepages pool for this,
> > do we? This is the same as using huge page mappings for the whole of
> > kernel space on ia32. As long as it's a kernel mapping, and 16MB aligned
> > and contig, we get it for free, surely?
> 
> The whole point of the patch is to not use the direct mapping, but
> use a different interleaved mapping on NUMA machines to spread
> the memory out over multiple nodes.

There is a middle ground, in theory.  At least on a NUMA machine you
can divide up the allocation roughly as requested_size/number_nodes.
Round the result up to the next available page size, and allocate
interleaved on the nodes until you've satisfied the requested size.
This minimizes the number of TLB entries required to interleave the
allocation.

However, as noted, the kernel barely handles two page sizes, much
less multiple page sizes.  If more flexible page-size handling
comes along someday this and many other sections of code could
stand to benefit from some rewriting.

> > > Using other page sizes would be probably tricky because the 
> > > linux VM can currently barely deal with two page sizes.
> > > I suspect handling more would need some VM infrastructure effort
> > > at least in the changed port. 
> > 
> > For the general case I'd agree. But this is a setup-time only tweak
> > of the static kernel mapping, isn't it?
> 
> It's probably not impossible, just lots of ugly special cases.
> e.g. how about supporting it for /proc/kcore etc? 

Just to bring a bit of closure regarding the patches I posted yesterday,
I'm reading the overall discussion as "The patches look good enough for
current kernels, and this would benefit from multiple page size support,
if we ever get it."  Fair read?

Brent

-- 
Brent Casavant                          If you had nothing to fear,
bcasavan@sgi.com                        how then could you be brave?
Silicon Graphics, Inc.                    -- Queen Dama, Source Wars
--
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:"aart@kvack.org"> aart@kvack.org </a>

  parent reply	other threads:[~2004-12-15 18:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-14 17:53 Brent Casavant
2004-12-14 18:59 ` Martin J. Bligh
2004-12-14 19:13   ` Andi Kleen
2004-12-14 19:48     ` Brent Casavant
2004-12-14 20:08     ` Martin J. Bligh
2004-12-14 23:24       ` Brent Casavant
2004-12-14 22:00         ` Martin J. Bligh
2004-12-15  4:58           ` Andi Kleen
2004-12-15 14:47             ` Anton Blanchard
2004-12-15 23:37               ` Brent Casavant
2004-12-16  5:02               ` Andi Kleen
2004-12-16  5:13                 ` Anton Blanchard
2004-12-16 14:18                   ` Jose R. Santos
2004-12-20 16:56                     ` Jose R. Santos
2004-12-21 11:46                       ` Anton Blanchard
2004-12-21 16:23                         ` Brent Casavant
2004-12-23  2:19                           ` Jose R. Santos
2004-12-15  4:08         ` Andi Kleen
2004-12-15  7:14           ` Martin J. Bligh
2004-12-15  7:17             ` Andi Kleen
2004-12-15 15:08               ` Martin J. Bligh
2004-12-15 18:24               ` Brent Casavant [this message]
2004-12-15  7:41           ` Eric Dumazet
2004-12-15  7:46             ` Andi Kleen
2004-12-15  9:14               ` Andi Kleen
2004-12-14 23:24     ` Nick Piggin
2004-12-14 19:30   ` Brent Casavant
2004-12-14 20:10     ` Martin J. Bligh
2004-12-14 18:32 Luck, Tony
2004-12-15  0:28 ` Hiroyuki KAMEZAWA
2004-12-15 17:25 Luck, Tony

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=Pine.SGI.4.61.0412151051270.24052@kzerza.americas.sgi.com \
    --to=bcasavan@sgi.com \
    --cc=ak@suse.de \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@aracnet.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