Re: uClibc and pthreads

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 [email protected] 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 [email protected] 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 [email protected] 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 -- [email protected]
>> To unsubscribe send an email to [email protected]
_______________________________________________
l4-hackers mailing list -- [email protected]
To unsubscribe send an email to [email protected]