Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263228AbTKEXmg (ORCPT ); Wed, 5 Nov 2003 18:42:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263275AbTKEXmf (ORCPT ); Wed, 5 Nov 2003 18:42:35 -0500 Received: from 224.Red-217-125-129.pooles.rima-tde.net ([217.125.129.224]:41963 "HELO cocodriloo.com") by vger.kernel.org with SMTP id S263228AbTKEXme (ORCPT ); Wed, 5 Nov 2003 18:42:34 -0500 Date: Thu, 6 Nov 2003 00:42:31 +0100 From: Antonio Vargas To: "Chen, Kenneth W" , linux-kernel@vger.kernel.org Subject: Re: [DMESG] cpumask_t in action Message-ID: <20031105234231.GA16122@wind.cocodriloo.com> References: <20031105232438.GA24817@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031105232438.GA24817@sgi.com> User-Agent: Mutt/1.3.28i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2162 Lines: 44 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. - 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/