lkml.org 
[lkml]   [1999]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:7.103 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site