On Thu, Mar 1, 2012 at 2:13 AM, Steven Whitehouse <swhiteho@xxxxxxxxxx> wrote:
>
> GFS2 is guilty as charged, m'lud! (but see below...)
>
> from fs/gfs2/dentry.c:
>
> static int gfs2_dhash(const struct dentry *dentry, const struct inode *inode,
> struct qstr *str)
> {
> str->hash = gfs2_disk_hash(str->name, str->len);
> return 0;
> }
Ok, that's fine. As long as you also use your own well-defined
hash-function rather than just depend on the default VFS one, I don't
care. It's only the default one I'd be optimizing.
You'd obviously not get the performance advantage either, but since I
don't even know whether it's really worth it in the first place, not a
big worry (those kernel routines can be about 5% of CPU time each
under loads that are very pathname-intensive, and it looks like I
could shave maybe 10-20% off them for the best case, so we're talking
*maybe* a percentage point on some specific loads).
And yeah, if some filesystem actually depends on the current default
VFS hash we can always work around it by filesystems just making the
current hash function explicit like you already do in gfs2.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
