Hi Marcus,
thank you very much for you fast and detailed answer! Overall this
should be really helpful for reconstructing what changes need to be done.
I would be very interested in the results of your measurements! Do you
already have other libpthread implementations in mind that you want to
look at? As noted in the BENCHMARKING file in l4re
(https://github.com/kernkonzept/mk/blob/master/BENCHMARKING) a heads
up to benchmark...@os.inf.tu-dresden.de on any measurements before
they are published would be highly appreciated so that we can
sanity-check them and if they match our experience with the
performance we see.
I already read this file before and will do so. If I got some results,
or any questions for that matter, I'll respond to this thread again
(regarding results more likely after sending them
to benchmark...@os.inf.tu-dresden.de first).
Thanks again!
Best regards
Pascal
On 1/24/24 20:54, Marcus Hähnel wrote:
Hi Pascal,
On 2024-01-24 12:53, Pascal Scholz wrote:
1) Is there a technical reason for L4Re still using the Linuxthreads
implementation and not some kind of NPTL port or other
implementations?
The libpthread implementation used in L4Re is based on the
linuxthreads (formerly named linuxthreads.old) implementation from
uClibc. There is no particular reason why one was chosen over the
other that I am aware of. In the end it doesn't matter that much,
since the "backend" is highly L4 specific anyways. I guess the
linuxthreads implementation was easier to port.
2) What uClibc is used exactly? Do you manage your own fork of uClibc
and back port relevant patches of uClibc-ng? Or do you use a uClibc-ng
with additional L4 patches? Or some completely other version? It seems
that the uClibc version used diverged in 2014 from the original. This
seems relevant to me as I wanted to check, which changes were done to
make the uClibc work with L4 (in an attempt to generate some kind of a
diff), so I might port them to another libc implementation.
Originally uClibc was used and adapted to L4Re. When uClibc was no
longer actively maintained we implemented some of the things we needed
ourselves or ported them from other C libraries. After uclibc-ng
gained traction we started first porting fixes and improvements from
them when we needed them. More recently we started to synchronize
uClibc with the current upstream uClibc-ng state and also already
contributed some of our changes back where this made sense to us. This
is not yet done but a work in progress and you will likely see more
changes to our uClibc during the next months.
In my project I would like to replace Linuxthreads with some other
pthreads implementation and measure the performance impacts of these
changes, so the aforementioned questions seem relevant to me.
The best start is probably to to look at the libpthread implementation
you find in l4re-core/uclibc/lib/libpthread and compare this to the
upstream/uclibc-ng version of these files. Though the upstream might
have diverged in the meantime. We only imported changes when they were
known to be performance critical or bug fixes but otherwise kept our
implementation stable so far. This might as well change once we caught
up with upstream uclibc-ng.
I would be very interested in the results of your measurements! Do you
already have other libpthread implementations in mind that you want to
look at? As noted in the BENCHMARKING file in l4re
(https://github.com/kernkonzept/mk/blob/master/BENCHMARKING) a heads
up to benchmark...@os.inf.tu-dresden.de on any measurements before
they are published would be highly appreciated so that we can
sanity-check them and if they match our experience with the
performance we see.
If you have any questions while looking at the code don't hesitate to
ask.
Best regards and happy hacking!
- Marcus
Thanks in advance for you time!
Kind regards,
Pascal
_______________________________________________
l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de
To unsubscribe send an email to l4-hackers-le...@os.inf.tu-dresden.de
_______________________________________________
l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de
To unsubscribe send an email to l4-hackers-le...@os.inf.tu-dresden.de
