dbuf_find() mutex contention #1291
Labels
Type: Performance
Performance improvement or performance problem
Milestone
Comments
|
@behlendorf I'm testing right now with: it's a bit early to say it's helping but so far it doesn't seem to have hurt (performance is the same not worse, I don't see rcu stalls (yet)) I'll probably leave this change in my tree for a while and revisit this in a week or two. |
|
@behlendorf I just noticed this was still open. As reported on IRC this did indeed help. |
|
@cwedgwood It helped by getting rid of the 'stall on CPU' messages or it measurably helped performance in some way? |
behlendorf
pushed a commit
to behlendorf/zfs
that referenced
this issue
Oct 23, 2014
Due to evidence of contention both the buf_hash_table and the dbuf_hash_table sizes have been increased from 256 to 8192. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#1291
behlendorf
pushed a commit
to behlendorf/zfs
that referenced
this issue
Oct 23, 2014
Due to evidence of contention both the buf_hash_table and the dbuf_hash_table sizes have been increased from 256 to 8192. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#1291
snajpa
pushed a commit
to vpsfreecz/zfs
that referenced
this issue
Nov 7, 2014
Due to evidence of contention both the buf_hash_table and the dbuf_hash_table sizes have been increased from 256 to 8192. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#1291 Signed-off-by: Pavel Snajdr <snajpa@snajpa.net>
snajpa
pushed a commit
to relbit/zfs
that referenced
this issue
Nov 8, 2014
Due to evidence of contention both the buf_hash_table and the dbuf_hash_table sizes have been increased from 256 to 8192. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#1291 Signed-off-by: Pavel Snajdr <snajpa@snajpa.net>
ryao
pushed a commit
to ryao/zfs
that referenced
this issue
Nov 29, 2014
Due to evidence of contention both the buf_hash_table and the dbuf_hash_table sizes have been increased from 256 to 8192. This increase in hash table size adds approximating 0.5M to our fixed memory footprint. This relatively small increase is not expected to cause problems even on low memory machines. This footprint will also become dynamic when the persistent L2ARC support is finalized. In the meanwhile, this small change significantly reduces contention for certain workloads. Signed-off-by: Chris Wedgwood <cw@f00f.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Pavel Snajdr <snajpa@snajpa.net> Closes openzfs#1291
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
kvm & arc fighting it out for memory
The text was updated successfully, but these errors were encountered: