lkml.org 
[lkml]   [2004]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] dentry and inode cache hash algorithm performance changes.
    * Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de> [2004-05-01 14:08:26 +0200]:
    > Judging from the graphs (!), I don't see a real difference for
    > dcache. There's just one outlier (depth 11) for the old hash function,
    > which seems to be translated to multiple depth 9 entries. The
    > histograms seem to confirm, that there's at most a minimal difference,
    > if they'd be equally scaled.
    >
    > Maybe this is due to qstr hashes, which were used by both approaches
    > as input?

    SpecSFS is not really the best benchmark to show the efficiency of the
    dentry hash function. I need to come up with a better defense for the
    this hash functions. While I did not do the study for this hash
    function, mathematically speaking this hash algorithm should always
    create a equal or better hash. SFS just shows equal (well, slightly
    better), so Ill work on getting some more data to back up the "better"
    claim.

    > The inode hash seems to be distributed more evenly with the new hash
    > function. Although the inode histogram suggests, that most buckets are
    > in the 0-2 depth range, with the old hash function leading slightly in
    > the zero depth range.

    Thats a good thing. With the new hash function, we get 25% more bucket
    usage and most of the bucket are only 1 object deep. This buckets take
    up memory so we better use them. The old hash functions was no very
    efficient in spreading the hashes across all the buckets, with the new
    hash function we have 4.5 times more buckets with only 1 object deep so
    it scales better as we increase the number of buckets as well.

    It also provides a 3% improvement on the overall SFS number with half
    the number of buckets use which I believe its a great improvement from
    just a hash algorithm change.

    -JRS
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:02    [W:0.027 / U:31.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site