The patches where merged in portage so this thread is obsolete. If you want these patches upgrade to 2.3.6-r3. See the Glibc 2.3.90 snapshot ebuilds thread instead for the 2.3.90 snapshot glibcs!

Creating custom kernels seems popuplar but I decided to be a bit different an created my own glibc ebuild instead. It started as a way of testing a couple of AMD64 performance patches from suse and mandrake and that's still it's main purpose and feature but it contains changes that benefits other arches as well. There is a bug report about geting those patches included in the official glibc and any feedback about them should also be posted to that bug (#100289). I recomend that you read this whole post before you try it yourself. And if you have any problems post them here but this is completely unsupported and you are using it at your own risk (as always. ). I hope to get some of these changes included in portage.

It's currently based on up to date glibc-2.3.6-r2 and 2.3.5.20050722 ebuilds but it also includes this (more details below):

No rebuilding or anything is needed and there should be no problems bootstraping with this glibc.

AMD64 performance enhancements:

These comes from an Mandriva SRPM from their latest 2006 release and they took them from Suse but they origin from AMD in the first place. The progress of getting these patches included in portage can be tracked in bug #100289.

*AMD64 optimized libm.
Contains an updated and optimized math library for AMD64 CPUs. Improvements can be seen in Seti@home and the Gimp for example, or anything that uses libm.

*AMD64 optimized string routines.
Increases memory copy performance for AMD64. The improvements can be seen with a small test-program, memcpy.c, which is attatched to the bug (compile it with -O at least).

That's an improvement of over 1000mb/s! Suse 9.3 and 10 also gives about 2300mb/s out of the box.

Generic enhancements

* --enable-kernel bumped to 2.6.9 or 2.611.
This prevents glibc from compiling in compatibility cruft making it leaner and meaner. Of course you need to be running a 2.6.9 or 2.6.11 kernel at least.

Added back the nomalloccheck USE-flag.
The nomalloccheck USE-flag was removed so I added it back. Having malloccheck on comes with a slight overhead and might prevent some buggy apps from running, a problem for binary only apps which you can't do much about. But there is a good reason it's on by default.

* Updated fedora tarball
Updated fedora add-ons from a Fedora SRPM.

* Gcc4 ssp support controlled by a gcc4ssp USE
The gcc4ssp USE-flag turns on SSP and fortify support. Only set this flag if you have a ssp/fortify capable gcc 4 since build will fail otherwise! It's based on chtephan's work. Works perfectly on x86, untested on other arches.

* Enabled building with binutils --as-needed
Enabled building with binutils --as-needed. This change got merged in glibc 2.3.5-r3 and later but the snapshot ebuilds still doesn't have it.

* Various fixes to make this build and work.
Patches from suse glibc-2.3.90-54.src.rpm.

* Binutils -Bdirect support for faster dynamic loading of libraries.
Adds support for the -Bdirect ld-flag to speed up dynamic loading of libraries (OpenOffice, Gnome, KDE for example). This flag breaks glibc so it's filtered out in the ebuild but I'm not sure if it breaks anything else. Why don't you help find out? Please share your experience with this flag in bug #114008. It requires binutils 2.16.1-r1 to work. As much as possible should be compiled with this flag for best effect. It can coexist with prelink and other LDFLAGS. You should also edit the file /etc/env.d/00basic and add LD_BIND_DIRECT="1". This feature is experimental!

* Binutils -Hashvals support (requires patches binutils)
Adds support for the -Hashvals linker flag (another optimization). To use this you need to create your own overlay for binutils too with the patch from bug #114008. This feature is also experimental!

Questions and answers

Will this break my system?
Probably not, none of the changes are very risky and the amd64 patches are already included in stable releases of mandriva and suse. But you are using it at your own risk so don't blame me if it installs Windows ME or something. I'm using it myself on several systems including my server which is up 24/7 and I don't have any problems.

dev-libs/apr fail to build against glibc 2.3.90
Run export ac_cv_func_pthread_mutexattr_setrobust_np=no before you emerge it.

I run modular X and are using -Bdirect and X fails to start
Recompile libXfont without -Bdirect to solve the problem.

What arches does it run on?
AMD64 and x86 are the primary arches because that's what I use but it should run on other arches as well. I tried to not break any of the other arches but I haven't tested it.

Are there any known problems?
A older version of the overlay caused some segfaults with nano and azureus. Make sure you run the latest if you have problems, then whine in this thread if it still doesn't work.

This patch also has problems building with a hardened GCC3 AMD64 toolchain. I don't know any good solutions to this except disabling it.

Is the changelog also included in the overlay?
Yes, check files/changelog.overlay.

Where does the patches come from?
See "AMD64 performance enhancements" above for the AMD64 patches. All patches except 2020 are the work of other people so kudos to them!

Build settings?
Anything should do but I've only tested this with nptl and nptlonly myself. But you might have problems building with the strings patch if you are on hardened or have -fstack-protector(-all) in your CFLAGS.

I recomend that you set the glibc-omitfp USE-flag, it builds all the libs twice, once with extra optimizations and once with the standard settings for debuging purposes. The optimized libraries are used by default. Using this USE-flag on a gcc4 system would normaly make your glibc big and slow but that's fixed in my overlay so now I recomend everyone to set this flag.

If you want to try the -Bdirect patch you need to install binutils 2.16.1-r1 (this exact version). Put -Wl,-Bdirect in your LDFLAGS to use it (after you emerged glibc and binutils with -Bdirect support)

If you want to try the -hashvals patch you need to create your own binutils overlay first. Then put -Wl,-hashvals in yout LDFLAGS. The binutils patch is in bug #114008.

2006-01-21
*New snapshot!
*Added back the -Bdirect patch to the 2.3.90 snapshot, apparently it got lost somwhere. (2.3.90.20060121)
*Removed a patch that clashes with -Bdirect. (2.3.90.20060121)
*Updated the ssp patch from portage. (2.3.6-r2)

2006-01-08 (2)
*Removed some left over digest files.

2006-01-08
*New snapshot, fixes a header problem (2.3.90.2060108)
*Updated the patchset, one of the patches had been partly merged.
*Fixed the ssp patch again.
*Removed the old snapshots.

2006-01-02
*New HEAD snapshot. (2.3.90.2060102)
*Updated fedora tarball. (2.3.90.2060102)
*The 20051211 snapshot is still included since it's known working.
*Synced with portage, now based on 2.3.6-r2 (2.3.6-r2)

2005-12-29 (2)
*Added back the 20051211 snapshot, the new one seems broken.

2005-12-29
*New HEAD snapshot. (2.3.90.20051229)
*Updated patches from suse. (2.3.90.20051229)
*Fixed the ssp patch to apply with the new branch update. (2.3.90.20051229)
*Synced with portage. (2.3.6-r1)

2005-12-13
*Fixed a problem with the ebuild accidently applying a patch that was supposed to be used with gcc4ssp only. (2.3.90.20051211)

First would they give any performance increase on Sempron Processors (32 bit AMD's in a 64 bit capable motherboard/slot)? The thought being that some of the allowable optimizations may be down to other fctors tan just the 64 bit architechture, architectural changes which may have also made it into the Sempron - improvements over the XP architecture.

Second - if the patch overlay is placed on a system which does not have such architecture, when you emerge, is its set up intelligent enough not to try to compile in optimizations on a machine it shouldnt (does it query the arch flags?)?

First would they give any performance increase on Sempron Processors (32 bit AMD's in a 64 bit capable motherboard/slot)? The thought being that some of the allowable optimizations may be down to other fctors tan just the 64 bit architechture, architectural changes which may have also made it into the Sempron - improvements over the XP architecture.

Second - if the patch overlay is placed on a system which does not have such architecture, when you emerge, is its set up intelligent enough not to try to compile in optimizations on a machine it shouldnt (does it query the arch flags?)?

clearly - these may not be known and may require testing.

Regards,
Orion

I doubt it, I would think the speedups come from using the 64bit registers on the AMD64 to their fullest, so on a 32bit cpu it should explode.

First would they give any performance increase on Sempron Processors (32 bit AMD's in a 64 bit capable motherboard/slot)? The thought being that some of the allowable optimizations may be down to other fctors tan just the 64 bit architechture, architectural changes which may have also made it into the Sempron - improvements over the XP architecture.

Second - if the patch overlay is placed on a system which does not have such architecture, when you emerge, is its set up intelligent enough not to try to compile in optimizations on a machine it shouldnt (does it query the arch flags?)?

clearly - these may not be known and may require testing.

Regards,
Orion

I don't think so. They only modifies the x86_64 parts of glibc which is not built on a x86 system.

How about puting the strings patch on hold then and focus on the libm patches?
So we can at least conclude that they are regression free and work on the
strings patch later. I've uploaded a new overlay tarball that no longer applies it:

Nice patches and thanks for providing them in such an easy to utilize fashion. No problems to report thus far, I've been using this patched version you're providing since yesterday while performing my installation routine from stage1, and nothing's blown up on me just yet.

I'll be sure to check out all the Java apps once I've had a chance to get them installed, and also just all my other apps in general. So far Fluxbox and the system in general has never felt snappier, but it's all subjective since I don't ever run benchmarks. My memcpy reports the following:

_________________Now the rainy season reminds me of Maria
The way she danced, the color of her hair
Now I'm locked inside a stall at the cantina
Eating the bananas and the cocaine off the mirror
Looking for a ticket to take me away from here

Well I personally reverted back to the "old" standard glibc just yesterday since I was encountering problems with my copy of GNU Nano not being able to search through documents, it would always segfault. There was one or two other apps that would give me problems that I can't quite recall at the moment, they were minor though and hard to reproduce, the Nano problem was the most prevalent. Since I text-edit using Nano religiously, however, I decided any speed boost from these patches isn't worth having to deal with a b0rked editor.

Surprised nobody else had this problem though, maybe my CFLAGS brought it about in conjunction with the glibc patches._________________Now the rainy season reminds me of Maria
The way she danced, the color of her hair
Now I'm locked inside a stall at the cantina
Eating the bananas and the cocaine off the mirror
Looking for a ticket to take me away from here

Well I personally reverted back to the "old" standard glibc just yesterday since I was encountering problems with my copy of GNU Nano not being able to search through documents, it would always segfault. There was one or two other apps that would give me problems that I can't quite recall at the moment, they were minor though and hard to reproduce, the Nano problem was the most prevalent. Since I text-edit using Nano religiously, however, I decided any speed boost from these patches isn't worth having to deal with a b0rked editor.

Surprised nobody else had this problem though, maybe my CFLAGS brought it about in conjunction with the glibc patches.

The nano problem is well known. I don't know what to do about it except downgrading to nano 1.2.x. Perhaps a recent CVS snapshot will do better?

So it may not be a good indicator of problems with the patches (btw running fine here for 3 weeks now!)_________________Routinely breaking NX, GNUstep, net-ftp, miscellaneous (llvm, filezilla, rdesktop, chromium, ...) packages