> On 12/7/17 7:54 PM, Frank Filz wrote: > > Stacked FSALs often depend on op_ctx->fsal_export being set. > > > > We also have lots of FSAL methods that take the fsal_export as a > parameter. > > > The latter sounds better. > > Now that we know every single thread local storage access involves a hidden > lock/unlock sequence in glibc "magically" invoked by the linker, it would be > better to remove as many TLS references as possible! > > After all, too many lock/unlock are a real performance issue. > > Perhaps we should pass op_ctx as the parameter instead.
I thought the lock was only to create the TLS variable, and not on every reference. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
