[Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY
Jan Vesely
jan.vesely at rutgers.edu
Sat Aug 6 14:32:13 UTC 2016
On Sat, 2016-08-06 at 13:00 +0200, ⚛ wrote:
> On Sat, Aug 6, 2016 at 4:34 AM, Rob Clark <robdclark at gmail.com>
> wrote:
> >
> > On Fri, Aug 5, 2016 at 8:42 PM, Jan Ziak <0xe2.0x9a.0x9b at gmail.com>
> > wrote:
> > >
> > > Mesa source code prior to this patch uses both RTLD_NOW and
> > > RTLD_LAZY.
> > > This patch removes all RTLD_NOW in favor of RTLD_LAZY.
> > >
> > > In comparison to early binding, lazy binding reduces CPU
> > > instruction count
> > > of small GL apps (e.g: glxinfo) by 6 million instructions.
> > > Larger apps won't notice the difference.
> > tbh, I don't know the background of existing places that use
> > RTLD_LAZY
> > instead of RTLD_NOW (but my experience w/ xserver using LAZY has
> > not
> > been positive, so I think going the other direction seems like a
> > good
> > idea)..
> We could add a verifier to the build process that tests the
> foo_dri.so
> libraries (as well as all other libs subject to dlopen by Mesa) for
> undefined symbols:
>
> $ LD_PRELOAD=libGL.so ldd -d -r radeonsi_dri.so \
> | grep "^undefined" && echo "red alert!"
>
> This will ensure that Mesa does not break apps after replacing all
> RTLD_NOWs with RTLD_LAZY.
>
> I am going to start writing a new patch verifying relevant *.so files
> at buildtime.
This won't help at all. the linking process already includes no-
undefined flag, so the build will fail at linking stage if symbols
can't be resolved.
RTLD_NOW detects bugs in deployment. IMO it's preferable if DE fails to
start instead of crashing hours into work. sure I can set LD_BIND_NOW
env var, but there are programs that have much stronger case for using
lazy binding (like LO) that would be negatively affected.
shaving 6M instructions does not seem like strong enough benefit to
justify this.
Jan
>
> >
> > But I'm not sure that optimizing for glxinfo is the best goal.
> I will turn my attention to manifestations of suboptimal Mesa GL in
> other apps as soon as I am satisfied with glxinfo/glxgears (and after
> the list of my patches at patchwork gets closer to zero).
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160806/9fa103e2/attachment.sig>
More information about the mesa-dev
mailing list