From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S264908AbUGMMdw@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S264908AbUGMMdw (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 13 Jul 2004 08:33:52 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264929AbUGMMdw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 13 Jul 2004 08:33:52 -0400
Received: from mx1.redhat.com ([66.187.233.31]:39838 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S264908AbUGMMdt (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 13 Jul 2004 08:33:49 -0400
From: David Howells <dhowells@redhat.com>
In-Reply-To: <20040713025643.GA7498@austin.ibm.com> 
References: <20040713025643.GA7498@austin.ibm.com>  <20040712175605.GA1735@rx8.austin.ibm.com> <20040713023721.GA7461@austin.ibm.com> 
To: "Jose R. Santos" <jrsantos@austin.ibm.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, slpratt@us.ibm.com
Subject: Re: [PATCH] Making i/dhash_entries cmdline work as it use to. 
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 13 Jul 2004 13:33:40 +0100
Message-ID: <4348.1089722020@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


> Actualy, it doesnt look like we need MAX_SYS_HASH_TABLE_ORDER at all so
> I'm resending the patch which now limits the max size of a hash table to
> 1/16 total memory pages.  This would keep people from doing dangerous
> things when using the hash_entries.

That's an enormous limit. Consider the fact that you will have a multiplicity
of such hash tables, each potentially eating 1/16th of your total memory
(remember, the bootmem allocator's only real limit is how big a chunk of
memory it can allocate in one go).

Do you have numbers to show that committing an eighth of your memory (8GB if
you have 64GB - two hash tables at 4GB apiece) to hash tables is almost
certainly not worth it.

For instance, the dcache:

	(*) Assuming 64GB of memory, of which 1/16th allocated to the dcache
	    hash table and 1/16th allocated to the inode hash table.

	(*) dcache hash buckets are 16 bytes apiece on PPC64.

	(*) 4GB hash table gives you 256 Meg hash buckets.

		(gdb) p ((4ULL<<30)/16) / 1024 / 1024
		$1 = 256

	(*) The dentry struct on PPC64 is approx 256 bytes in size.

	(*) The remaining 56GB could provide 224 Meg dentries if allocated to
	    nothing else.

		(gdb) p (56ULL<<30) / 256 / 1024 / 1024
		$2 = 224

	(*) So you'd end up with more buckets in the hash table than you could
	    possibly allocate dentry structures.

David