To: linux-kernel@vger.kernel.org
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Horrible L2 cache effects from kernel compile
Date: Tue, 25 Feb 2003 22:18:09 +0000 (UTC)
Organization: Transmeta Corporation
Message-ID: <b3gq31$2h8$1@penguin.transmeta.com>
References: <3E5BB7EE.5090301@colorfullife.com>
NNTP-Posting-Date: 25 Feb 2003 22:22:42 GMT
Cache-Post-Path: palladium.transmeta.com!unknown@penguin.transmeta.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1492
Lines: 35

In article <3E5BB7EE.5090301@colorfullife.com>,
Manfred Spraul  <manfred@colorfullife.com> wrote:
>
>Are you sure that this will help?

It might, under some loads.

However, I don't think it's a long-term solution, since the hashing will
mean that for any reasonably spread out load you _will_ always walk all
dentries.

So the long-term solution is to either use a local lookup (which we
ended up doing for the page cache) _or_ to limit the number of dentries
themselves some way.  The latter sounds like a bad idea.

>Btw, has anyone tried to replaced the global dcache with something 
>local, perhaps a tree instead of d_child, and then lookup in d_child_tree?

I'd love to see somebody try.  The main worry is the overhead required
per directory dentry and keeping it scalable.  The dentry tree _will_ be
quickly populated and one common case is a few huge directories, yet at
the same time for most dentries there won't be any children at all or
very few of them). 

Right now the "child" list is just a simple linked list, and changing
that to something more complex might make it possible to get rid of the
hash entirely. But increasing the size of individual dentries is a bad
idea, so it would have to be something fairly smart.

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