All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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.