https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Gleb Natapov from comment #23) > I am not sure I agree. 64 lock will take one page of memory, which is > negligible amount nowadays and we can drop the array if compiled for single > threaded machine. It is perhaps negligible for your app, but libc has lots of users with different needs. And dl_load_lock isn't the only widely used lock in libc, are we going to use page of array locks in each case such lock has scalability issues with certain use cases? > Such interface will make new dl_iterate_phdr_rd to libgcc specific, also > scalablity will depend on cache efficiency, so while benchmark will show > much better result, real application will not benefit. Complex C++ > applications tend to have deep call chains. Why would it be libgcc specific? It would be another libc supported API, with clear documentation on what it does and any user could just use it. As I said, the number of entries in the cache could be extended.
