Messages in this thread | | | Date | Sat, 30 Oct 1999 03:33:10 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: questions about new buffer hash |
| |
On Fri, 29 Oct 1999, David S. Miller wrote:
>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/
| |