code review: zfsvfs_hold/rele need to pass the correct tags through to rrw_enter(). The existing code will not work (if reference_tracking_enable), because you will be holding with tag "zfsvfs_hold" and releasing with "zfsvfs_rele". The existing code holds and releases with tag e.g. "zfs_prop_set_userquota"; that needs to remain the case.
I think it would be cleaner to encapsulate the multitude of locks within the rrw code, but I can live with it as is. --matt On Thu, Jun 5, 2014 at 12:34 PM, Alexander Motin <[email protected]> wrote: > Hi again! Another day, another patch. :) > > Testing the same setup as in earlier "Godfather ZIO lock congestion" > thread (small strided reads from 256 threads concurrently on 40-core > machine) but with ARC size sufficient to fit all test data, I hit another > lock congestion on RRW lock of zfsvfs->z_teardown_lock. Earlier I've seen > the same congestion even on smaller machine while profiling SPEC NFS > benchmark. > > To avoid the congestion with attached patch I've replaced single teardown > RRW lock per struct vfszfs with bunch (17) of them. Read acquisitions are > randomly distributed among them based on curthread pointer to avoid any > measurable congestion in a hot path. Write acquisition are going to all the > locks, but they should be rare enough to not bother. > > As result, performance on this test setup increased from ~475K IOPS to > ~1.3M IOPS. > > Any comments? > > -- > Alexander Motin > > _______________________________________________ > 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
