On Fri, Nov 29, 2013 at 1:36 PM, Saso Kiselkov <[email protected]>wrote:
> The only "good" reason I can think of is read-write locks not being > present in the kernel when this was written. rwlocks definitely existed (in the solaris kernel) when ZFS was written. I'm not sure why we used a hand-rolled reader-writer lock rather than a krwlock_t. Maybe George knows? Other than that, the > spa_config_lock semantics are exactly the same as in krwlock_t. > > > Is there some kind of lock debugging facility in illumos kernel? > > You'll have to be a bit more specific. There's plenty of lock analysis > and debugging tools, but that's really not what we're after here. We're > after the semantics. I think I understand the krwlock_t semantics from > looking at the code (and they appear identical to FreeBSD's, though I > haven't looked at Linux), and as far as I can discern, the code in that > webrev gives the exact same behavior as the legacy spa_config_locks > implementation. > Using a rwlock would lose the debugability of the refcount_t scl_count (tag matching, ::refcount). That may be acceptable, though. > > > Are they agree to live with this too? > > If it improves performance and you can demonstrate that in testing (some > info on the tests you ran + results and possibly nice graphs would be > greatly appreciated), then I have no doubt Illumos will welcome this. > After all, why not? > Agreed, I'd also like to see the numbers (and test information, pool configuration (zpool list -v), etc). --matt > Cheers, > -- > Saso > _______________________________________________ > 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
