lkml.org 
[lkml]   [2004]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dentry bloat.


On Sat, 8 May 2004, David S. Miller wrote:
>
> FWIW this patch does not change the dentry size on sparc64.
> It's 256 bytes both before and after. But of course the
> inline string length is larger.

Yup. I tested it on ppc64, that was part of the reason for the increase in
the inline string size ("reclaim the lost space" rather than "make the
dentry shrink from 256 bytes to 248 bytes").

That shows how broken the old setup was, btw: on 64-bit architectures, the
old code resulted in the inline string size being 16 bytes, while on a P4
it would be something like 120 bytes. That makes no sense.

Btw, the cacheline alignment was actually likely to guarantee the
_worst_ possible cache behaviour on a P4: the fields we access on lookup
are:

- d_hash (pointer *2)
- d_bucket (pointer)
- d_move_count (unsigned long)
- d_name.hash (part of a struct with 1 pointer + 2 ints)
- d_parent (pointer)

and they were all close together, but I think "d_bucket" was guaranteed to
be in another cacheline exactly because of the thing always being aligned.
So removing the alignment is likely to cause more of the lookups to only
need one cacheline instead of two like it was before.

I think. Maybe I counted the offsets wrong.

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: 2009-11-18 23:46    [W:0.122 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site