I'd like to see this use of TLS as a "hidden parameter" replaced regardless. It has been a source of bugs, and locks us into a pthreads execution model I think needlessly.
Matt On Fri, Dec 8, 2017 at 10:07 AM, Frank Filz <ffilz...@mindspring.com> wrote: >> 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 -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 ------------------------------------------------------------------------------ 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
