Date: Wed, 5 Aug 2015 23:04:48 -0400 From: Rich Felker <dalias@...c.org> To: Andy Lutomirski <luto@...nel.org> Cc: musl@...ts.openwall.com Subject: Re: Re: Further dynamic linker optimizations On Wed, Aug 05, 2015 at 03:37:25PM -0700, Andy Lutomirski wrote: > >>>>- The whole outer for loop in find_sym is the hot path for > >>>> performance. As such, eliminating the lazy calculation of > >>>>gnu_hash and simply doing it before the loop should be a > >>>>measurable win, just by removing the if (!ghm) branch. > >>> > >>>On a related note, it's possible to avoid calculating sysv hash, if > >>>gnu-hash is enabled system-wide, by not setting 'global' flag on > >>>the vdso item (as mentioned on IRC in your conversation with Timo). > >> > >>Yes, and I think this sounds like a worthwhile approach. Seeing > >>timings for it would be great. :-) > > > >I told them earlier in IRC. But on the same i7 box and running "clang > >--version" which has 100+ DT_NEEDED... removing vdso and thus sysv > >hashing had magnitude of tens of milliseconds. (I wonder how it'd > >perform if we calculated both sysv and gnu hashes at same time.) > > /me dons vdso maintainer hat. > > I can add a GNU hash to the vdso quite easily (for Linux 4.3). > Would that be helpful? Yes, and I'd lean towards doing this unless you can see any disadvantages to weigh it against (using more pages? would that matter?). But either way I think we should make the change on the musl side too. It doesn't make sense for the vdso to appear in the global namespace unless it was actually pulled in by dlopen/RTLD_GLOBAL. For actually using the vdso symbols, we don't use the dynamic linker anyway; we look them up directly so that they work with static linking (and because the way the dynamic linker/libc is linked precludes vdso symbols getting used to resolve its own references, anyway). Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.