lkml.org 
[lkml]   [2003]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Horrible L2 cache effects from kernel compile
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.087 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site