Quoting Dave Chinner (2013-07-08 08:44:53) > [cc fsdevel because after all the XFS stuff I did a some testing on > mmotm w.r.t per-node LRU lock contention avoidance, and also some > scalability tests against ext4 and btrfs for comparison on some new > hardware. That bit ain't pretty. ] > > And, well, the less said about btrfs unlinks the better: > > + 37.14% [kernel] [k] _raw_spin_unlock_irqrestore > + 33.18% [kernel] [k] __write_lock_failed > + 17.96% [kernel] [k] __read_lock_failed > + 1.35% [kernel] [k] _raw_spin_unlock_irq > + 0.82% [kernel] [k] __do_softirq > + 0.53% [kernel] [k] btrfs_tree_lock > + 0.41% [kernel] [k] btrfs_tree_read_lock > + 0.41% [kernel] [k] do_raw_read_lock > + 0.39% [kernel] [k] do_raw_write_lock > + 0.38% [kernel] [k] btrfs_clear_lock_blocking_rw > + 0.37% [kernel] [k] free_extent_buffer > + 0.36% [kernel] [k] btrfs_tree_read_unlock > + 0.32% [kernel] [k] do_raw_write_unlock > Hi Dave, Thanks for doing these runs. At least on Btrfs the best way to resolve the tree locking today is to break things up into more subvolumes. I've got another run at the root lock contention in the queue after I get the skiplists in place in a few other parts of the Btrfs code. -chris _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
