Date: Tue, 21 Jun 2022 09:56:53 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Tomas Kolda <koldat@gmail.com>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Native Alpine GLibc support (NEW)
Message-ID: <20220621095653.71773d59@ncopa-desktop.lan>
In-Reply-To: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 21 Jun 2022 09:32:44 +0200
Tomas Kolda <koldat@gmail.com> wrote:

> Trying to send email again from my personal email as my previous post
> was marked as invalid.
> 
> Hi,
> 
hi!

...
> 4. We have switched to native MUSL based everywhere (Java, libs,
> etc.). I was happy that it was possible, but I was surprised that the
> performance of our applications degraded a lot. Our application is
> heavily multithreaded. After long investigation I have found that
> degradation is because of poor implementation of pthread locks in
> muslc. Probably the advantage of glibc  is the adaptive locking
> feature and maybe other types of tunings. In our example application
> spends with muslc build 600% CPU  in kernel and 200% in user space,
> but on glibc 100% CPU in kernel and 700% in user space (where 100%
> means 1 CPU core). Yes it is that huge difference.

Do you have any smallish testcases where we can test this?

> At this point I had many options of what to do and one I would like to describe.
> 
> - I started thinking that I would like to have a variant of Alpine
> with glibc. Everything else is the same and great as usual.

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.

> - After the initial painful bootstrap to get bare minimum to be able
> to compile I got the first 300 packages built (enough for us) with
> only a few tweaks in some packages that are explicitly applying MUSL
> patches. I simply disabled these.
> - Now our application is running fast again with native builds and no tweaks.
> - I know glibc is maybe a little bit, but we simply need performance
> and compatibility.
> 
> Example of change in procps. There is a tweak to make it work in MUSL
> so I simply conditionally disable it:
> if [ "$CLIBC" != "glibc" ]; then
> export LIBS="$LIBS -lintl"
> fi

I believe someone did this some years ago, but stopped due to lack of
resources.

And this might also be of interest:
https://twitter.com/ariadneconill/status/1527642520167108609

> I would love to have the patches part of the main branch so I do not
> need to do merges from time to time. I can only dream that the Alpine
> community will provide the official build as well. I think that more
> people would like that when I look at a number of projects around
> hacking glibc in Alpine.
> 
> Please do not take it as a heretical thought. It came as a need.
> 
> What do you think about the project? I can share my changes in some
> branch or in github. I can also share initial 3.16 binaries to have an
> easier bootstrap. It was really a pain.

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.

> Thank you very much for your project and the hard work you put into
> it. Tomas