On Wed, Jul 23, 2014 at 10:47 PM, Prakash Surya <[email protected]> wrote:
> Out of curiosity, is the workload used to measure the 18% performance > benefit as simple as it seems? i.e. fill the arc, then do reads which > are guaranteed to be arc hits? > That's right. --matt > > -- > Cheers, Prakash > > On Wed, Jul 23, 2014 at 10:06:09PM -0700, Matthew Ahrens wrote: > > Good point, it should be consistent with the others. Review updated. > > --matt > > > > On Wed, Jul 23, 2014 at 9:50 PM, Prakash Surya <[1] > [email protected]> > > wrote: > > > > Why not prefix the variable with "zfs_" like the rest of the > > parameters? > > Seems reasonable otherwise, I've seen large hash lengths on the > > Linux > > port running Lustre-ZFS MDS servers which makes use of many 512B > > buffers. > > -- > > Cheers, Prakash > > On Wed, Jul 23, 2014 at 08:36:29PM -0700, Matthew Ahrens wrote: > > > [1][2]https://reviews.csiden.org/r/61/ > > > > > 5034 ARC's buf\_hash\_table is too small > > > > > Reviewed by: George Wilson <[2][3][email protected]\> > > > Reviewed by: Christopher Siden > > <[3][4][email protected]\> > > > > > Original author: Matthew Ahrens > > > The ARC puts all (non-anonymous) arc_buf_hdr_t's in a hash table, > > which > > > is > > > created at system boot time. The hash table is sized such that > if > > all > > > of > > > physical memory was filled with 64K blocks, the hash chain length > > would > > > average > > > less than 1.0. However, on a system with typical block size of > > 8k, > > > this can lead to > > > long hash chain lengths. I've observed average length ~6.5; > > > theoretically it > > > could be up to 16 (because evicted "ghost" entries are also in > the > > > hashtable). > > > By increasing the hash table size to have enough entries for > > average > > > length 1.0 > > > when memory is filled with 8k blocks, we can obtain a 18% > > performance > > > improvement on cached reads. (680MB/s -> 805MB/s) > > > The hash table size should also be tunable, rather than hard > > coded. > > > --matt > > > > > > > > References > > > > > > 1. [5]https://reviews.csiden.org/r/61/ > > > 2. mailto:[6][email protected] > > > 3. mailto:[7][email protected] > > > _______________________________________________ > > > developer mailing list > > > [8][email protected] > > > [9]http://lists.open-zfs.org/mailman/listinfo/developer > > > > References > > > > 1. mailto:[email protected] > > 2. https://reviews.csiden.org/r/61/ > > 3. mailto:[email protected] > > 4. mailto:[email protected] > > 5. https://reviews.csiden.org/r/61/ > > 6. mailto:[email protected] > > 7. mailto:[email protected] > > 8. mailto:[email protected] > > 9. http://lists.open-zfs.org/mailman/listinfo/developer > > > _______________________________________________ > > developer mailing list > > [email protected] > > http://lists.open-zfs.org/mailman/listinfo/developer > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
