Hello, On Mon, 3 Apr 2017 15:53:28 -0700, Vineet Gupta wrote:
> > What do you think about following patch? > > We had some discussion about this recently on the buildroot > > mailinglist. Any other use cases other than rpcbind/nfs-utils you > > can think of? > > So there's a small downside to this - which I reckon will likely not stand > out in > grand scheme of things - still tabling it here for people to be aware of. > This can potentially degrade some of the micro-benchmarks such as LMBench > lat_proc > shell - since there's now an additional shared library (libtirpc) to load. We > spotted this back in 2015 when comparing buildroot (using libtirpc) vs. our > homegrown builds (using native toolchain rpc). How big was the performance hit? Is it just due to loading an additional library, or to internal RPC implementation aspects that differs between the uClibc built-in implementation and the libtirpc implementation? If it's just due to loading an additional library, is this micro benchmark really representative of real-world workload? Is it really a real life situation to have very short-lived processes that need RPC support? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
