I am thinking that this kind of dentry would take limited space in an
auxiliary dcache.
> If you are doing massive lookups after readdir you are very likely to do
> it sequentially.
This is only true if you do not care about inode read & seek
performance.
Admittedly I only know of one program that does care, and I am writing
it :-) Still, as it may replace the search engine of GNU find in time
you may consider it a worthwhile test case.
There are two rules:
1. On almost all filesystems, calling stat() or open() in inode order
gives better performance because inode order correlates well with
order on disk, thus reducing seek times. This includes NFS if the
remote filesystem has this property, both unfsd and knfsd.
On some filesystems where this is not true (mostly network ones and
the FAT ones now), the inode numbers are generated sequentially so
performance is the same as reading in directory order anyway.
Summary: I don't know of any filesystem where this strategy is worse
than reading in directory order, and there are several where it is
better.
2. When deciding which items in a directory are subdirectories and which
are not, guessing by name is surprisingly helpful. Combine that with
the i_nlink optimisation and recursive directory search performance
is improved significantly.
-- Jamie
> Moreover, you will create additional pressure on dcache
> and I suspect that it will cancel all benefits.
One way around this is to separate the pressure due to these kinds of
dentries from normal hashed dentries, or to limit this kind in some way.
Note that "dentry with inode"s are /much/ smaller than hashed dentries
with inodes: it's the inode that's the dominant space consumer.
Which brings on another idea: "dentry without inode" allows the
possibility of reclaiming memory by freeing inodes but not their
dentries.
> Try it - you will get seriously more complex code and a hit on
> performance.
It's obvious that there will be a hit on performance; what's not obvious
to me is where, or whether there are potential gains to outweigh the
loss.
Try it -- I start by trying to warm you up to implementing it for me ;-)
-- jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/