Re: [DMESG] cpumask_t in action

Antonio Vargas
2003-11-05T23:42:36Z

On Wed, Nov 05, 2003 at 03:24:38PM -0800, Jesse Barnes wrote:
> 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, what about making hash_size = scale * log(mem_size), so that the
tables are not scaled too high on your very-high-end boxes? ;)

--
winden/network

1. Dado un programa, siempre tiene al menos un fallo.
2. Dadas varias lineas de codigo, siempre se pueden acortar a menos lineas.
3. Por induccion, todos los programas se pueden
reducir a una linea que no funciona.