Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
future of the libc6.1-alphaev67 package
1 view
Skip to first unread message
Aurelien Jarno
Aug 24, 2021, 5:20:04 PM8/24/21
to
Dear alpha porters,
With the removal of the libc6-xen package in glibc 2.32, the only
package still using the hwcap infrastructure is libc6.1-alphaev67. The
hwcap infrastructure consists in upstream support for looking for
libraries in the hwcap directories, plus Debian specific patches to
support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
in the maintainer scripts to disable hwcap support until all libc6
packages are configured.
The various optimized packages have been replaced with time by other
mechanisms such as indirect function support (IFUNC), or runtime atomic
selection in GCC (-moutline-atomics).
I would therefore like to discuss the future of the libc6.1-alphaev67
package on alpha. According to popcon, to take with a grain of salt
given the low number of submissions, this package is installed on 20% of
the installations. I wonder if this package is really useful in terms of
performance, or if the architecture baseline can be raised to ev67, or
to a ev6 as a compromise. The goal is to stop building this package.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://www.aurel32.net
With the removal of the libc6-xen package in glibc 2.32, the only
package still using the hwcap infrastructure is libc6.1-alphaev67. The
hwcap infrastructure consists in upstream support for looking for
libraries in the hwcap directories, plus Debian specific patches to
support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
in the maintainer scripts to disable hwcap support until all libc6
packages are configured.
The various optimized packages have been replaced with time by other
mechanisms such as indirect function support (IFUNC), or runtime atomic
selection in GCC (-moutline-atomics).
I would therefore like to discuss the future of the libc6.1-alphaev67
package on alpha. According to popcon, to take with a grain of salt
given the low number of submissions, this package is installed on 20% of
the installations. I wonder if this package is really useful in terms of
performance, or if the architecture baseline can be raised to ev67, or
to a ev6 as a compromise. The goal is to stop building this package.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://www.aurel32.net
Michael Cree
Aug 24, 2021, 10:10:04 PM8/24/21
to
On Tue, Aug 24, 2021 at 10:59:32PM +0200, Aurelien Jarno wrote:
> I would therefore like to discuss the future of the libc6.1-alphaev67
> package on alpha. According to popcon, to take with a grain of salt
> given the low number of submissions, this package is installed on 20% of
> the installations. I wonder if this package is really useful in terms of
> performance, or if the architecture baseline can be raised to ev67, or
> to a ev6 as a compromise. The goal is to stop building this package.
I think we should raise the baseline to include the byte-word
> I would therefore like to discuss the future of the libc6.1-alphaev67
> package on alpha. According to popcon, to take with a grain of salt
> given the low number of submissions, this package is installed on 20% of
> the installations. I wonder if this package is really useful in terms of
> performance, or if the architecture baseline can be raised to ev67, or
> to a ev6 as a compromise. The goal is to stop building this package.
extension (BWX) which I think would be EV56. In addition to
giving some optimisations generally to libc it would eliminate
a class of unaligned access bugs across the archive where gcc
performs an optimisation based on a flawed determination that
certain alignment exists in the memory access of a byte or
16-bit word.
Cheers,
Michael.
John Paul Adrian Glaubitz
Aug 25, 2021, 1:50:02 AM8/25/21
to
Hello!
On 8/24/21 10:59 PM, Aurelien Jarno wrote:
> With the removal of the libc6-xen package in glibc 2.32, the only
> package still using the hwcap infrastructure is libc6.1-alphaev67. The
> hwcap infrastructure consists in upstream support for looking for
> libraries in the hwcap directories, plus Debian specific patches to
> support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
> in the maintainer scripts to disable hwcap support until all libc6
> packages are configured.
>
> The various optimized packages have been replaced with time by other
> mechanisms such as indirect function support (IFUNC), or runtime atomic
> selection in GCC (-moutline-atomics).
Isn't this type of architecture optimization support currently seeing a
revival due to many distributions looking into providing optimized x86_64
variants? [1]
Adrian
> [1] https://www.phoronix.com/scan.php?page=news_item&px=Fedora-2021-x86_64-Level
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 8/24/21 10:59 PM, Aurelien Jarno wrote:
> With the removal of the libc6-xen package in glibc 2.32, the only
> package still using the hwcap infrastructure is libc6.1-alphaev67. The
> hwcap infrastructure consists in upstream support for looking for
> libraries in the hwcap directories, plus Debian specific patches to
> support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
> in the maintainer scripts to disable hwcap support until all libc6
> packages are configured.
>
> The various optimized packages have been replaced with time by other
> mechanisms such as indirect function support (IFUNC), or runtime atomic
> selection in GCC (-moutline-atomics).
revival due to many distributions looking into providing optimized x86_64
variants? [1]
Adrian
> [1] https://www.phoronix.com/scan.php?page=news_item&px=Fedora-2021-x86_64-Level
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Aurelien Jarno
Sep 2, 2021, 5:30:04 PM9/2/21
to
On 2021-08-25 07:46, John Paul Adrian Glaubitz wrote:
> Hello!
>
> On 8/24/21 10:59 PM, Aurelien Jarno wrote:
> > With the removal of the libc6-xen package in glibc 2.32, the only
> > package still using the hwcap infrastructure is libc6.1-alphaev67. The
> > hwcap infrastructure consists in upstream support for looking for
> > libraries in the hwcap directories, plus Debian specific patches to
> > support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
> > in the maintainer scripts to disable hwcap support until all libc6
> > packages are configured.
> >
> > The various optimized packages have been replaced with time by other
> > mechanisms such as indirect function support (IFUNC), or runtime atomic
> > selection in GCC (-moutline-atomics).
>
> Isn't this type of architecture optimization support currently seeing a
> revival due to many distributions looking into providing optimized x86_64
> variants? [1]
Yes, but that's unrelated. The plan is not to drop the hwcap mechanism
> Hello!
>
> On 8/24/21 10:59 PM, Aurelien Jarno wrote:
> > With the removal of the libc6-xen package in glibc 2.32, the only
> > package still using the hwcap infrastructure is libc6.1-alphaev67. The
> > hwcap infrastructure consists in upstream support for looking for
> > libraries in the hwcap directories, plus Debian specific patches to
> > support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
> > in the maintainer scripts to disable hwcap support until all libc6
> > packages are configured.
> >
> > The various optimized packages have been replaced with time by other
> > mechanisms such as indirect function support (IFUNC), or runtime atomic
> > selection in GCC (-moutline-atomics).
>
> Isn't this type of architecture optimization support currently seeing a
> revival due to many distributions looking into providing optimized x86_64
> variants? [1]
from upstream code (which btw got extended in glibc 2.33). That will
still be supported for instance for scientific libraries like in the
link you provided. The goal is to stop providing optimized glibc through
the hwcap mechanism (as the optimization is done using GCC or GNU IFUNC
for many architectures), so that we can get rid of all the code enabling
safe upgrade of the libc6 package. This part is Debian specific because
we need to support online upgrades, so version version mismatch between
base and hwcap libraries must not happen.
If optimizations for the ev67 CPU is essential, an alternative is to
ship both the base and hwcap versions in the same libc6.1 package. This
causes an additional 4 MiB of possibly useless files to be installed on
a system, something that has been considered too big for other
architectures. Before going that way, we should check if the resulting
optimization is worth the hassle, especially that we have to disable bit
rotting assembly code from upstream (both baseline and alphaev67
optimized) to get the testsuite passing.
Aurelien Jarno
Sep 2, 2021, 5:40:02 PM9/2/21
to
Hi,
That's really interesting. If raising the baseline to EV56 also helps to
eliminate other bugs, it's something worth considering. Do you know if
there is a lot of hardware not compatible with this baseline? Also do
you have an idea if there is a big difference between EV56 and EV67
optimized code?
eliminate other bugs, it's something worth considering. Do you know if
there is a lot of hardware not compatible with this baseline? Also do
you have an idea if there is a big difference between EV56 and EV67
optimized code?
Aurelien Jarno
May 14, 2023, 4:00:03 PM5/14/23
to
Hi,
The legacy hwcap code, that was deprecated since glibc 2.33 has been
removed from glibc 2.37, and there is no support for the new mechanism
for the alpha architecture.
Therefore the libc6.1-alphaev67 package will be removed from the debian
package with glibc 2.37. We can take the opportunity to raise the
baseline if needed.
Regards
removed from glibc 2.37, and there is no support for the new mechanism
for the alpha architecture.
Therefore the libc6.1-alphaev67 package will be removed from the debian
package with glibc 2.37. We can take the opportunity to raise the
baseline if needed.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://aurel32.net
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
John Paul Adrian Glaubitz
May 14, 2023, 4:10:05 PM5/14/23
to
Hello!
On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> Therefore the libc6.1-alphaev67 package will be removed from the debian
> package with glibc 2.37. We can take the opportunity to raise the
> baseline if needed.
I think we agreed on raising it to EV56, didn't we?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> Therefore the libc6.1-alphaev67 package will be removed from the debian
> package with glibc 2.37. We can take the opportunity to raise the
> baseline if needed.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
Aurelien Jarno
May 14, 2023, 4:50:15 PM5/14/23
to
On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote:
> Hello!
>
> On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> > Therefore the libc6.1-alphaev67 package will be removed from the debian
> > package with glibc 2.37. We can take the opportunity to raise the
> > baseline if needed.
>
> I think we agreed on raising it to EV56, didn't we?
It was not clear to me from the current thread, but I guess the
> Hello!
>
> On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> > Therefore the libc6.1-alphaev67 package will be removed from the debian
> > package with glibc 2.37. We can take the opportunity to raise the
> > baseline if needed.
>
> I think we agreed on raising it to EV56, didn't we?
discussion have been continued somewhere else.
Could you please take care of raising the baseline at the GCC level? In
the meantime, I'll force -mcpu=ev56 at the glibc level.
John Paul Adrian Glaubitz
May 15, 2023, 6:20:04 AM5/15/23
to
Hi Aurelien!
On Sun, 2023-05-14 at 22:47 +0200, Aurelien Jarno wrote:
> On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote:
> > Hello!
> >
> > On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> > > Therefore the libc6.1-alphaev67 package will be removed from the debian
> > > package with glibc 2.37. We can take the opportunity to raise the
> > > baseline if needed.
> >
> > I think we agreed on raising it to EV56, didn't we?
>
> It was not clear to me from the current thread, but I guess the
> discussion have been continued somewhere else.
>
> Could you please take care of raising the baseline at the GCC level? In
> the meantime, I'll force -mcpu=ev56 at the glibc level.
Yes, absolutely. I will file a bug report against GCC asking for the baseline raise.
On Sun, 2023-05-14 at 22:47 +0200, Aurelien Jarno wrote:
> On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote:
> > Hello!
> >
> > On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> > > Therefore the libc6.1-alphaev67 package will be removed from the debian
> > > package with glibc 2.37. We can take the opportunity to raise the
> > > baseline if needed.
> >
> > I think we agreed on raising it to EV56, didn't we?
>
> It was not clear to me from the current thread, but I guess the
> discussion have been continued somewhere else.
>
> Could you please take care of raising the baseline at the GCC level? In
> the meantime, I'll force -mcpu=ev56 at the glibc level.
Michael Cree
May 19, 2023, 5:30:03 PM5/19/23
to
On Mon, May 15, 2023 at 12:13:04PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Aurelien!
>
> On Sun, 2023-05-14 at 22:47 +0200, Aurelien Jarno wrote:
> > On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote:
> > > Hello!
> > >
> > > On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> > > > Therefore the libc6.1-alphaev67 package will be removed from the debian
> > > > package with glibc 2.37. We can take the opportunity to raise the
> > > > baseline if needed.
> > >
> > > I think we agreed on raising it to EV56, didn't we?
> >
> > It was not clear to me from the current thread, but I guess the
> > discussion have been continued somewhere else.
> >
> > Could you please take care of raising the baseline at the GCC level? In
> > the meantime, I'll force -mcpu=ev56 at the glibc level.
>
> Yes, absolutely. I will file a bug report against GCC asking for the baseline raise.
Thanks for doing this!
> Hi Aurelien!
>
> On Sun, 2023-05-14 at 22:47 +0200, Aurelien Jarno wrote:
> > On 2023-05-14 22:06, John Paul Adrian Glaubitz wrote:
> > > Hello!
> > >
> > > On Sun, 2023-05-14 at 21:53 +0200, Aurelien Jarno wrote:
> > > > Therefore the libc6.1-alphaev67 package will be removed from the debian
> > > > package with glibc 2.37. We can take the opportunity to raise the
> > > > baseline if needed.
> > >
> > > I think we agreed on raising it to EV56, didn't we?
> >
> > It was not clear to me from the current thread, but I guess the
> > discussion have been continued somewhere else.
> >
> > Could you please take care of raising the baseline at the GCC level? In
> > the meantime, I'll force -mcpu=ev56 at the glibc level.
>
> Yes, absolutely. I will file a bug report against GCC asking for the baseline raise.
Cheers,
Michael.
0 new messages