----- Original Message -----
From: "Saso Kiselkov" <[email protected]>
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).
How about the case where the admin has specifically sized a smaller
zfs_arc_max to keep ZFS / ARC memory requirements down as they want
the memory for other uses, and there is no L2ARC.
In this case sizing the hash based of the machine physmem could counter
act this and hence cause a problem, could it not?
I know its extreme but for example a machine with 256GB of ram but
zfs_arc_max set to 1GB you'd be allocating 256MB of that as the hash
size, which is surely a massive waste as you wouldn't need 256MB of
hash for just 1GB of ARC buffers?
Am I still barking up the wrong tree?
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to [email protected].
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
