lkml.org 
[lkml]   [2003]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [DMESG] cpumask_t in action
From
On Wed, Nov 05, 2003 at 03:18:29PM -0800, Chen, Kenneth W wrote:
> > Dentry cache hash table entries: 33554432 (order: 14, 268435456 bytes)
> > Inode-cache hash table entries: 33554432 (order: 14, 268435456 bytes)
> > IP: routing cache hash table of 8388608 buckets, 131072Kbytes
> > TCP: Hash tables configured (established 67108864 bind 65536)
> > swapper: page allocation failure. order:17, mode:0x20
>
> Does these hash tables really need to that big? 33 million dentry and
> inode entry? Same thing with network, unless the machine is loaded
> with several gigabit cards, these hash table seems to be exceedingly
> large.

This one only has two gige cards:

tg3.c:v2.2 (August 24, 2003)
PCI: Found IRQ 54 for device 0000:01:04.0
ACPI: No IRQ known for interrupt pin A of device 0000:01:04.0 - using IRQ 54
eth0: Tigon3 [partno(030-1771-000) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000BaseT Ethernet 08:00:69:13:e6:a7
PCI: Found IRQ 66 for device 0000:11:04.0
ACPI: No IRQ known for interrupt pin A of device 0000:11:04.0 - using IRQ 66
eth1: Tigon3 [partno(030-1771-000) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000BaseT Ethernet 08:00:69:13:e4:a4
PCI: Found IRQ 53 for device 0000:01:03.0
ACPI: No IRQ known for interrupt pin A of device 0000:01:03.0 - using IRQ 53

As for the dentry and inode-cache tables, yes they're probably too big,
and they're also allocated on node 0 rather than being spread out.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.123 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site