On 10/17/13 12:24 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Saso Kiselkov" <skiselkov...@gmail.com> > To: <developer@open-zfs.org>; "illumos-zfs" <z...@lists.illumos.org> > Sent: Thursday, October 17, 2013 12:09 AM > Subject: [OpenZFS Developer] [Review] Tunable ARC buf hash sizing > > >> Okay, I've reworked and simplified the ARC buf hash changes to just >> change the way we size the hash table and bump up the amount of hash >> tables we allocate to 1MB/1GB. >> Webrev: http://cr.illumos.org/~webrev/skiselkov/new_buf_hash/ >> Issue: https://www.illumos.org/issues/4218 > > Did you mean "This index is then masked with ht_mask" (remove > the word "by"?) in the following: > + * which spits out a 64-bit hash index. This index is then masked > + * by with ht_mask to obtain the final index into the hash table:
You're right, I was hastily editing the description to correspond to the 1D hash table stuff and forgot to delete a preposition. Updated. > It may be a silly question but should the hash sizing not be based > around zfs_arc_max instead of physmem? I don't see much reason to tie these two together. The in-memory size of the ARC (zfs_arc_max) is independent of the performance of hash lookups on it (keep in mind that the ARC also holds references to buffers in the L2ARC). -- Saso _______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
