MIME-Version: 1.0
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
 <20220621095653.71773d59@ncopa-desktop.lan>
In-Reply-To: <20220621095653.71773d59@ncopa-desktop.lan>
From: Tomas Kolda <koldat@gmail.com>
Date: Tue, 21 Jun 2022 10:49:07 +0200
Message-ID: <CAGFcrMmniJdjO54SHR+Js=5pyuB70A_M0Ge92=pFpxjbBHYC9w@mail.gmail.com>
Subject: Re: Native Alpine GLibc support (NEW)
Cc: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=C3=BAt 21. 6. 2022 v 9:57 odes=C3=ADlatel Natanael Copa <ncopa@alpinelinux=
.org> napsal:
>
> Do you have any smallish testcases where we can test this?
>
I do not have a small test. Synthetic applications does not give the
best results. I am sure it is the issue as the only change is glibc
vs. musl and kernel profiler point to pthread locking. There is a spin
lock that wastes the CPU time in system space. Glibc have some
heuristics to not get into the kernel that often (adaptive locking)
which as a result brigs a lot of speed. JDK has no other dependency
than C library.

Anyway I will try to prepare some Java app that can show this.
>
> Would it be an idea to try fix the performance problems in musl libc
> instead? It would probably be significantly less maintenance work long
> term.
>
Yes this was one of my options. I was looking in glibc pthread
implementation and it looks to me that they save some statistical
features for adaptive locking in the structure. That as a result would
require change of size of mutex object and that would require
recompilation of all binaries. That is I think not acceptable.
Performance tuning these low level functions is more like a magic and
very sensitive (what helps one workload can break other). I am not
sure how long glibc was tuning that so yes it looks like the best
solution, but I am not sure if it is really doable under one year or
so. We can ask MUSL community after I would be able to create a test.
>
> I believe someone did this some years ago, but stopped due to lack of
> resources.
>
I definitely do not want to create new distro. It is really only about
conditionally disabling some line here and there. I think it is like
around 50 lines of changes in 10 packages to be able to compile 300
packages so far. I was actually surprised how easy it is now after I
have compiled build-base, abuild and apk-tools, because now I can
reuse it to build it itself again easily (new versions). I build in
docker.
>
> We are already struggling with resources, full disks, many incoming
> issues, feature requests, technical debt (lack of tests and/or
> documentation) etc. I am personally feeling I'm almost able to keep my
> head above the surface.
>
> So if this project can help solve our current issues, and contribute
> with more resources for the project as a whole, then sure. But if this
> is going to add more work for us long term, or even worse, someone do
> the initial work and then dump the maintenance work on our laps after
> there are a significant amount of users depending on it, then please no
> thanks.
>
> I would rather spend the resources on fixing the issues with musl.
>
I completely agree and understand your view. Unfortunately I am not in
a position to offer or fund the resources. Yes it can bring users and
yes it can generate additional issues.

My intention really was to have a pure Alpine built against glibc. It
is a C library as a MUSL. Everything else is exactly same. I remember
how much we were fighting with all variants of dependencies that are
coming as glibc based, because many users are still on
CentOS/Redhat/Debian/Ubuntu/etc. Glibc is mostly the blocker. That is
also why I was not going to try to improve the MUSL as at the end I
would hit the wall, because of another glibc based component.

Anyway if there is some interest just let me know.

Thanks,
Tomas