>I hope this satisfies all of your curiosities Andrea.
Yes definitely. I appreciated to know the details very much. Many
thanks!!!
The only two thoughts that cames to my mind now are:
o you didn't considered the time that you need to compute the
hashfn at all. With an almost empty hashtable the hashfn
computation cost will be the only cost you have to reach the
interesting data.
I agree that this may be a minor issue but it's not obvious we
can avoid to consider it in real life.
o The other more interesting issue is that while I agree completly
in your way to generate the hashfn starting from the empirical
data, I am not completly sure if I can trust the empirical data
to be generic enough to build a generic buffer layer hashfn (of
course I trust such hashfn is the _very_ best for your setup ;).
With your completly empirical approch you may have optimized the
hashfn for ext2 (and ext2+raid) patterns. This because for example the
metadata on ext2 can't flow on the whole disk (there's no inode
map in ext2) and depending on the layout of your filesystem and
the size of your hashtable, you may found the
per-group-fixed-located metadata colliding in very special
(not generic) buckets (and so you may need to ignore some
special bit in the block_nr that is never hit by metadata writes).
So it's not obvious to me that the fixed bits remains the same
without using ext2 for example.
If you still have saved the empirical data to fill the hash in the
simlator I could try to write an hashfn without the hardwired -6/-3/-12/13
that seems not generic enough to me. Then you could give a try in one
second to see if my one will be very worse. I think for example that the
shifts could be completly in function of the bh_hash_shift.
Andrea
-
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/