From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andi Kleen <ak@suse.de>, Brent Casavant <bcasavan@sgi.com>
Cc: 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: Tue, 14 Dec 2004 23:14:46 -0800 [thread overview]
Message-ID: <686170000.1103094885@[10.10.2.4]> (raw)
In-Reply-To: <20041215040854.GC27225@wotan.suse.de>
>> > > I originally was a bit worried about the TLB usage, but it doesn't
>> > > seem to be a too big issue (hopefully the benchmarks weren't too
>> > > micro though)
>> >
>> > Well, as long as we stripe on large page boundaries, it should be fine,
>> > I'd think. On PPC64, it'll screw the SLB, but ... tough ;-) We can either
>> > turn it off, or only do it on things larger than the segment size, and
>> > just round-robin the rest, or allocate from node with most free.
>>
>> Is there a reasonably easy-to-use existing infrastructure to do this?
>
> No. It will be a lot of work actually, requiring new code for
> each architecture and may even be impossible on some.
> The current hugetlb code is not really suitable for this
> because it requires an preallocated pool and only works
> for user space.
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?
> Also at least on IA64 the large page size is usually 1-2GB
> and that would seem to be a little too large to me for
> interleaving purposes. Also it may prevent the purpose
> you implemented it - not using too much memory from a single
> node.
Yes, that'd bork it. But I thought that they had a large sheaf of
mapping sizes to chose from on ia64?
> 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?
I'm not saying it needs doing now. But it's an interesting future
enhancement.
M.
--
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>
next prev parent reply other threads:[~2004-12-15 7:14 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 [this message]
2004-12-15 7:17 ` Andi Kleen
2004-12-15 15:08 ` Martin J. Bligh
2004-12-15 18:24 ` Brent Casavant
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='686170000.1103094885@[10.10.2.4]' \
--to=mbligh@aracnet.com \
--cc=ak@suse.de \
--cc=bcasavan@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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