Hi, Vineet Gupta wrote, > Hi Thomas, > > On 04/03/2017 09:57 PM, Thomas Petazzoni wrote: > >> 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? > > Processor, Processes - times in microseconds - smaller is better > ------------------------------------------------------------------------------ > Host OS Mhz null null open slct sig sig fork exec sh > call I/O stat clos TCP inst hndl proc proc proc > --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- > A7-720mhz Linux 3.4.61 720 0.50 0.97 4.37 9.38 26.0 1.00 5.59 1103 5061 8432 > A7-720mhz Linux 3.4.61 720 0.50 0.96 4.24 9.31 26.0 1.00 5.59 1093 5029 10.K > > So ~19% > > > 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? > > So the thing is Busybox binary ends up being linked with 2 libs (instead of > just > libc.so) thus ldso loading takes more time. Now lat_proc shell ends up doing > exec() of (busybox) shell and then hello world - hence the increased time. > > > > 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? > > Hard to judge really - for a desktop/server system it probably doesn't matter > - > but for a typical embedded system ...
You are not forced to use busybox with libtirpc. You only need it for NFS stuff. For modern NFS stack with rpcbind and nfs-utils you need libtirpc anyway. Busybox just implements a mount helper which could use internal uClibc RPC implementation. But in the end you need libtirpc on the embedded device. So avoid busybox+libtirpc and use rpcbind+nfs-utils+libtirpc if you require NFS on your device. I still see no real use case for the old internal RPC implementation on a modern embedded device. best regards Waldemar _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
