From: Eric Dumazet <dada1@cosmosbay.com>
To: Andi Kleen <ak@suse.de>
Cc: Brent Casavant <bcasavan@sgi.com>,
"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 07:41:25 +0000 [thread overview]
Message-ID: <41BFEAA5.1090109@cosmosbay.com> (raw)
In-Reply-To: <20041215040854.GC27225@wotan.suse.de>
Andi Kleen wrote:
>
> I actually considered implementing it for x86-64 some time ago
> for the modules, but then I never bothered. On AMD systems
> I actually prefer to use small pages here. The reason is that
> Opteron has a separated large and small pages TLB and the small
> pages TLB is much bigger. When someone else uses huge TLB
> pages too (user space or kernel direct mapping) then it's actually
> a good idea to use small pages.
Interesting...
I actually use dual Opterons systems, with very large route cache hashes
and tcp hashes. (rhash_entriesR4288 thash_entriesR4288), and a
Hugetlb aware user space programs.
x86info tells me (maybe wrongly)
Family: 15 Model: 5 Stepping: 8
CPU Model : Opteron
Instruction TLB: Fully associative. 32 entries.
Data TLB: Fully associative. 32 entries.
and /proc/cpuinfo tells me :
model name : AMD Opteron(tm) Processor 248
TLB size : 1088 4K pages
My questions are :
1) Are the route cache and tcp hashes use big pages (2MB) on 2.6.5/2.6.9
x86_64 kernels.
2) What are the exact number of data TLB entries (for small pages and
huge ones) for opterons ?
3) All networks interrupts are handled by CPU0. Should we really use
NUMA interleaved memory for hashes in this case ?
Thank you
Eric Dumazet
WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <dada1@cosmosbay.com>
To: Andi Kleen <ak@suse.de>
Cc: Brent Casavant <bcasavan@sgi.com>,
"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 08:41:25 +0100 [thread overview]
Message-ID: <41BFEAA5.1090109@cosmosbay.com> (raw)
In-Reply-To: <20041215040854.GC27225@wotan.suse.de>
Andi Kleen wrote:
>
> I actually considered implementing it for x86-64 some time ago
> for the modules, but then I never bothered. On AMD systems
> I actually prefer to use small pages here. The reason is that
> Opteron has a separated large and small pages TLB and the small
> pages TLB is much bigger. When someone else uses huge TLB
> pages too (user space or kernel direct mapping) then it's actually
> a good idea to use small pages.
Interesting...
I actually use dual Opterons systems, with very large route cache hashes
and tcp hashes. (rhash_entries=524288 thash_entries=524288), and a
Hugetlb aware user space programs.
x86info tells me (maybe wrongly)
Family: 15 Model: 5 Stepping: 8
CPU Model : Opteron
Instruction TLB: Fully associative. 32 entries.
Data TLB: Fully associative. 32 entries.
and /proc/cpuinfo tells me :
model name : AMD Opteron(tm) Processor 248
TLB size : 1088 4K pages
My questions are :
1) Are the route cache and tcp hashes use big pages (2MB) on 2.6.5/2.6.9
x86_64 kernels.
2) What are the exact number of data TLB entries (for small pages and
huge ones) for opterons ?
3) All networks interrupts are handled by CPU0. Should we really use
NUMA interleaved memory for hashes in this case ?
Thank you
Eric Dumazet
WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <dada1@cosmosbay.com>
To: Andi Kleen <ak@suse.de>
Cc: Brent Casavant <bcasavan@sgi.com>,
"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 08:41:25 +0100 [thread overview]
Message-ID: <41BFEAA5.1090109@cosmosbay.com> (raw)
In-Reply-To: <20041215040854.GC27225@wotan.suse.de>
Andi Kleen wrote:
>
> I actually considered implementing it for x86-64 some time ago
> for the modules, but then I never bothered. On AMD systems
> I actually prefer to use small pages here. The reason is that
> Opteron has a separated large and small pages TLB and the small
> pages TLB is much bigger. When someone else uses huge TLB
> pages too (user space or kernel direct mapping) then it's actually
> a good idea to use small pages.
Interesting...
I actually use dual Opterons systems, with very large route cache hashes
and tcp hashes. (rhash_entries=524288 thash_entries=524288), and a
Hugetlb aware user space programs.
x86info tells me (maybe wrongly)
Family: 15 Model: 5 Stepping: 8
CPU Model : Opteron
Instruction TLB: Fully associative. 32 entries.
Data TLB: Fully associative. 32 entries.
and /proc/cpuinfo tells me :
model name : AMD Opteron(tm) Processor 248
TLB size : 1088 4K pages
My questions are :
1) Are the route cache and tcp hashes use big pages (2MB) on 2.6.5/2.6.9
x86_64 kernels.
2) What are the exact number of data TLB entries (for small pages and
huge ones) for opterons ?
3) All networks interrupts are handled by CPU0. Should we really use
NUMA interleaved memory for hashes in this case ?
Thank you
Eric Dumazet
--
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:41 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-14 17:53 [PATCH 0/3] NUMA boot hash allocation interleaving Brent Casavant
2004-12-14 17:53 ` Brent Casavant
2004-12-14 17:53 ` Brent Casavant
2004-12-14 18:32 ` Luck, Tony
2004-12-14 18:32 ` Luck, Tony
2004-12-14 18:32 ` Luck, Tony
2004-12-15 0:28 ` Hiroyuki KAMEZAWA
2004-12-15 0:28 ` Hiroyuki KAMEZAWA
2004-12-15 0:28 ` Hiroyuki KAMEZAWA
2004-12-14 18:59 ` Martin J. Bligh
2004-12-14 18:59 ` Martin J. Bligh
2004-12-14 18:59 ` Martin J. Bligh
2004-12-14 19:13 ` Andi Kleen
2004-12-14 19:13 ` Andi Kleen
2004-12-14 19:13 ` Andi Kleen
2004-12-14 19:48 ` Brent Casavant
2004-12-14 19:48 ` Brent Casavant
2004-12-14 19:48 ` Brent Casavant
2004-12-14 20:08 ` Martin J. Bligh
2004-12-14 20:08 ` Martin J. Bligh
2004-12-14 20:08 ` Martin J. Bligh
2004-12-14 23:24 ` Brent Casavant
2004-12-14 23:24 ` Brent Casavant
2004-12-14 23:24 ` Brent Casavant
2004-12-14 22:00 ` Martin J. Bligh
2004-12-14 22:00 ` Martin J. Bligh
2004-12-14 22:00 ` Martin J. Bligh
2004-12-15 4:58 ` Andi Kleen
2004-12-15 4:58 ` Andi Kleen
2004-12-15 4:58 ` Andi Kleen
2004-12-15 14:47 ` Anton Blanchard
2004-12-15 14:47 ` Anton Blanchard
2004-12-15 14:47 ` Anton Blanchard
2004-12-15 23:37 ` Brent Casavant
2004-12-15 23:37 ` Brent Casavant
2004-12-15 23:37 ` Brent Casavant
2004-12-16 5:02 ` Andi Kleen
2004-12-16 5:02 ` Andi Kleen
2004-12-16 5:02 ` Andi Kleen
2004-12-16 5:13 ` Anton Blanchard
2004-12-16 14:18 ` Jose R. Santos
2004-12-16 14:18 ` Jose R. Santos
2004-12-16 14:18 ` Jose R. Santos
2004-12-20 16:56 ` Jose R. Santos
2004-12-20 16:56 ` Jose R. Santos
2004-12-20 16:56 ` Jose R. Santos
2004-12-21 11:46 ` Anton Blanchard
2004-12-21 11:46 ` Anton Blanchard
2004-12-21 11:46 ` Anton Blanchard
2004-12-21 16:23 ` Brent Casavant
2004-12-21 16:23 ` Brent Casavant
2004-12-21 16:23 ` Brent Casavant
2004-12-23 2:19 ` Jose R. Santos
2004-12-23 2:19 ` Jose R. Santos
2004-12-23 2:19 ` Jose R. Santos
2004-12-15 4:08 ` Andi Kleen
2004-12-15 4:08 ` Andi Kleen
2004-12-15 4:08 ` Andi Kleen
2004-12-15 7:14 ` Martin J. Bligh
2004-12-15 7:14 ` Martin J. Bligh
2004-12-15 7:14 ` Martin J. Bligh
2004-12-15 7:17 ` Andi Kleen
2004-12-15 7:17 ` Andi Kleen
2004-12-15 7:17 ` Andi Kleen
2004-12-15 15:08 ` Martin J. Bligh
2004-12-15 15:08 ` Martin J. Bligh
2004-12-15 15:08 ` Martin J. Bligh
2004-12-15 18:24 ` Brent Casavant
2004-12-15 18:24 ` Brent Casavant
2004-12-15 18:24 ` Brent Casavant
2004-12-15 7:41 ` Eric Dumazet [this message]
2004-12-15 7:41 ` Eric Dumazet
2004-12-15 7:41 ` Eric Dumazet
2004-12-15 7:46 ` Andi Kleen
2004-12-15 7:46 ` Andi Kleen
2004-12-15 7:46 ` Andi Kleen
2004-12-15 9:14 ` Andi Kleen
2004-12-15 9:14 ` Andi Kleen
2004-12-15 9:14 ` Andi Kleen
2004-12-14 23:24 ` Nick Piggin
2004-12-14 23:24 ` Nick Piggin
2004-12-14 23:24 ` Nick Piggin
2004-12-14 19:30 ` Brent Casavant
2004-12-14 19:30 ` Brent Casavant
2004-12-14 19:30 ` Brent Casavant
2004-12-14 20:10 ` Martin J. Bligh
2004-12-14 20:10 ` Martin J. Bligh
2004-12-14 20:10 ` Martin J. Bligh
2004-12-15 17:25 ` Luck, Tony
2004-12-15 17:25 ` Luck, Tony
2004-12-15 17:25 ` Luck, Tony
-- strict thread matches above, loose matches on Subject: below --
2004-12-20 23:36 Brent Casavant
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=41BFEAA5.1090109@cosmosbay.com \
--to=dada1@cosmosbay.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 \
--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 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.