On Thu, Jul 24, 2014 at 2:26 AM, Steven Hartland <[email protected]>
wrote:

> Is it worth increasing the default value as well?
>
>
I decreased the default value from 64K to 8K.  What value do you think
would be appropriate, and why?

--matt


>    Steve
>
> ----- Original Message ----- From: "Matthew Ahrens" <[email protected]>
> To: "Prakash Surya" <[email protected]>
> Cc: "developer" <[email protected]>; "illumos-zfs" <
> [email protected]>
> Sent: Thursday, July 24, 2014 6:06 AM
> Subject: Re: [OpenZFS Developer] [review request] 5034 ARC's
> buf_hash_table is too small
>
>
>
>  Good point, it should be consistent with the others.  Review updated.
>>
>> --matt
>>
>>
>> On Wed, Jul 23, 2014 at 9:50 PM, Prakash Surya <[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]https://reviews.csiden.org/r/61/
>>> >    5034 ARC's buf\_hash\_table is too small
>>> >    Reviewed by: George Wilson <[2][email protected]\>
>>> >    Reviewed by: Christopher Siden <[3][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. https://reviews.csiden.org/r/61/
>>> >    2. mailto:[email protected]
>>> >    3. mailto:[email protected]
>>>
>>> > _______________________________________________
>>> > 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
>>
>>
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer

Reply via email to