Message-ID: <3E5BB7EE.5090301@colorfullife.com>
Date: Tue, 25 Feb 2003 19:37:34 +0100
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
MIME-Version: 1.0
To: Andi Kleen <ak@suse.de>
CC: linux-kernel@vger.kernel.org, Dave Hansen <haveblue@us.ibm.com>
Subject: Re: Horrible L2 cache effects from kernel compile
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1069
Lines: 34

Andi wrote:

>The reason:
>
>Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
>Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
>
>(1GB) I bet on your big memory box it is even worse. No cache
>in the world can cache that.
>
[snip]

>Try the appended experimental patch. It replaces the hash table madness
>with relatively small fixed tables.
>  
>
Are you sure that this will help?
With a smaller table, you might cause fewer cache misses for the table 
lookup. Instead you get longer hash chains. Walking linked lists 
probably causes more cache line misses than the single array lookup.

Dave, how many entries are in the dcache?

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?

--
    Manfred

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