Date: Thu, 10 Jun 2004 02:12:28 +1000
From: Anton Blanchard <anton@samba.org>
To: Andi Kleen <ak@suse.de>
Cc: manfred@colorfullife.com, akpm@osdl.org, linux-kernel@vger.kernel.org,
       jrsantos@austin.ibm.com, mbligh@aracnet.com
Subject: Re: [PATCH] Use numa policy API for boot time policy
Message-ID: <20040609161228.GB6152@krispykreme>
References: <20040605034356.1037d299.ak@suse.de> <40C12865.9050803@colorfullife.com> <20040605041813.75e2d22d.ak@suse.de> <20040605023211.GA16084@krispykreme> <20040605122239.4a73f5e8.ak@suse.de> <20040609154429.GA6152@krispykreme> <20040609175613.487903b5.ak@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040609175613.487903b5.ak@suse.de>
User-Agent: Mutt/1.5.6i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 980
Lines: 25

 
> For what? 

No idea, I just want to convince myself that there arent any out there.

> IMHO 16MB hash table for a kernel structure is madness. A different data
> structure is probably needed if it's really a problem
> (is your dcache that big?). Or maybe just limit the dcache more aggressively
> to keep the max number of entries smaller.

Yep, specSFS (an NFS benchmark) shows this up quite badly. I think Jose
and Martin were looking at strategies for keeping the dcache under
control.

This was on a machine with only 64GB of RAM, if we had an NFS server
with more memory then its reasonable to want more memory dedicated to
dentries. At that point we either need to increase the hash or look at
using another structure.

Anton
-
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/