20 Mar
2017
20 Mar
'17
5:21 p.m.
Hi,
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?
best regards
Waldemar
20 Mar
20 Mar
7:51 p.m.
Hello,
On Mon, 20 Mar 2017 18:21:45 +0100, Waldemar Brodkorb 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?
I had a quick look in Buildroot to see which packages currently only
work with "native RPC" (i.e provided by the C library) and not with
libtirpc. Notice that when I say don't work, I mean "not supported by
Buildroot", which doesn't mean that the package cannot handle libtirpc,
just that it is not done in Buildroot.
- autofs, depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC only
- openvmtools, depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC only
- portmap, obviously. But I believe we could get rid of this package
entirely, it is deprecated and rpcbind is the official replacement.
- samba4, depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC only
And that's it. So it leaves three packages to really analyze and see
the impact.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
8:34 p.m.
Thomas, All,
On 2017-03-20 20:51 +0100, Thomas Petazzoni spake thusly:
Hello,
On Mon, 20 Mar 2017 18:21:45 +0100, Waldemar Brodkorb wrote:
We have the homepage pointing to LFS.org:
http://www.linuxfromscratch.org/blfs/view/svn/general/autofs.html
Autofs Dependencies
Optional
libtirpc-1.0.1 [...]
So we may be able to make it work with libtirpc in the end...
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?
I had a quick look in Buildroot to see which packages currently only
work with "native RPC" (i.e provided by the C library) and not with
libtirpc. Notice that when I say don't work, I mean "not supported by
Buildroot", which doesn't mean that the package cannot handle libtirpc,
just that it is not done in Buildroot.
- autofs, depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC only - openvmtools, depends on
BR2_TOOLCHAIN_HAS_NATIVE_RPC only
And it is not available for uClibc toolchains. Making it glibc-only
would not be too problematic, given the type of package this is.
- portmap, obviously. But I believe we could get rid
of this package
entirely, it is deprecated and rpcbind is the official replacement.
Maybe drop it, especially since nothing depends on or selects it.
- samba4, depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC
only
Given the size of the package, I doubt having it depends on glibc would
be too bad.
And when glibc actually drops their internal rpc, then samba will have
to add suopport for an alternative implementation.
Regards,
Yann E. MORIN.
And that's it. So it leaves three packages to
really analyze and see
the impact.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
8:40 p.m.
All,
On 2017-03-20 21:34 +0100, Yann E. MORIN spake thusly:
I had a quick look at bLFS again, and they recommend building against
libtirpc:
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/samba.html
So we may in the end be also able to switch entirely to using libtirpc.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
On 2017-03-20 20:51 +0100, Thomas Petazzoni spake
thusly:
> On Mon, 20 Mar 2017 18:21:45 +0100, Waldemar Brodkorb 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?
> I had a quick look in Buildroot to see which packages currently only
> work with "native RPC" (i.e provided by the C library) and not with
> libtirpc.
[--SNIP--]
- samba4,
depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC only
Given the size of the package, I doubt having it depends on glibc would
be too bad.
And when glibc actually drops their internal rpc, then samba will have
to add suopport for an alternative implementation. 
3 Apr
3 Apr
10:53 p.m.
On 03/20/2017 10:21 AM, Waldemar Brodkorb wrote:
Hi,
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).
-Vineet
4 Apr
4 Apr
4:57 a.m.
Hello,
On Mon, 3 Apr 2017 15:53:28 -0700, Vineet Gupta wrote:
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
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).
7:43 p.m.
Hi Thomas,
On 04/03/2017 09:57 PM, Thomas Petazzoni wrote:
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%
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?
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 ...
-Vineet
Best regards,
Thomas
8:44 p.m.
Hi,
Vineet Gupta wrote,
Hi Thomas,
On 04/03/2017 09:57 PM, Thomas Petazzoni wrote:
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%
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
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?
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 ...
8:48 p.m.
On 04/04/2017 01:44 PM, Waldemar Brodkorb wrote:
Right as I mentioned in my first post, I'm not arguing for/against, I'm just
sharing an observation, which was subtle when I first ran into it ! This might not
matter in the grand scheme of things !
-Vineet
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.
2823
days inactive
2838
days old
8 comments
4 participants
participants (4)
-
Thomas Petazzoni -
Vineet Gupta -
Waldemar Brodkorb -
Yann E. MORIN