Search:  
Gentoo Wiki

HOWTO_Optimise_glibc


Please format this article according to the guidelines and Wikification suggestions, then remove this notice {{Wikify}} from the article


Contents

Introduction

Glibc is the free library which provides system calls and other basic operators for most of the GNU/Linux systems. As C is the most common language used for programming Linux, glibc is used a lot and can really be considered a core part of the system. Glibc can be optimized for your system so that it operates faster by a number of means. The optimizations you are able to perform naturally depend on the system you are using and what you are using it for. This is mainly done using the USE flags available during emerge. Before you attempt the following it is recommended you know what USE flags are and how to use them. The relevant guide is here.

Optimizing Glibc Compilation

The effect of CFLAGS

Compiling Glibc with GCC affects the core code glibc uses. Glibc can identify that GCC is the compiler and this triggers optimizations depending on the CFLAGS used. Read more here. So just by choosing relevant CFLAGS for your system, you have started to optimize glibc.

Enabling further optimizations

You can also place glibc-omitfp in your USE flags. Remerge glibc by running.

Code: Remerging glibc
emerge --newuse -v world

Glibc and any relevant dependencies should then compile. This flag activates the -enable-omitfp configure option when compiling glibc. It means glibc will use -fomit-frame-pointer and other extra optimizations for the build. This flag maximizes the optimizations in glibc and, for debugging purpose, provides two sets of libraries; the first 'optimized' and the second 'standard'. The optimized libraries are used by default but you can choose to use the 'standard' libraries if you need to debug an application. This does increase the size of glibc and the compile time, and the standard -fomit-frame-pointer caveat applies, ie this WILL make the 'optimized' libraries impossible to debug. It MAY also provoke some compiler bugs, but appears to be basically safe - you have been warned!

Threading Models

glibc supports 2 different threading models, the older linuxthreads and the newer nptl. By default, glibc compiles a linuxthreads version also unless you specify the nptlonly useflag. Unless you are running legacy software you want to specify the nptl useflag. If you are running a modern system without any 3rd party binary packages it is probably safe to run nptlonly which will save you from compiling glibc twice as it wont compile the linuxthreads version. For a useful/interesting article in the differences between the two models try this article from IBM.

Locales

This is mainly based upon a tip from the Gentoo weekly newsletter November 8, 2004, that can be found in our Locales guide. You can choose which locales (which are the local keyboard characters, local keyboard setup, time etc) to build at install. If you don't limit the locales used on your system then usually all available locales starting from aa_DJ (Afar locale for Djibouti) through en_GB (English locale for the Great Britain) to zu_ZA.utf8 (Zulu locale for South Africa) will be installed. By limiting the locales built you can save 90% of the space taken up by storing these systems on your system, save the compilation time required building the locales settings for each package and as a handy side effect, make the compilation of glibc itself a lot faster. Unless you really need them all (and I can't think who would) then it's best to limit them to an absolute minimum.

Procedure

As of glibc-2.3.6-r4 or glibc-2.4-r2, the file /etc/locale.gen should contain the list of locales to be installed:

File: nano -w /etc/locale.gen
# Read the stuff at the top of the file for more info!
en_US.UTF-8 UTF-8
en_US ISO-8859-1

de_DE.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE@euro ISO-8859-15

You can find the list of valid combinations in the file /usr/share/i18n/SUPPORTED.

Old method

Prior to glibc-2.3.6-r4 and glibc-2.4-r2, we use the USE flag userlocales to make sure only those locales mentioned in /etc/locales.build are built and installed.

Edit your /etc/make.conf with your favorite text editor, and place userlocales somewhere in between the "" of the USE="" line.

Alternatively you can place this in /etc/portage/package.use using the following commands

Code: Activating the userlocales USE flag for glibc
echo "sys-libs/glibc userlocales" >> /etc/portage/package.use

Now you can specify the locales you want to use:

File: nano -w /etc/locales.build
#Read the stuff at the top of the file for more info!
en_US/ISO-8859-1
en_US.UTF-8/UTF-8
#en_GB/ISO-8859-1
#en_GB.UTF-8/UTF-8
de_DE/ISO-8859-1
de_DE@euro/ISO-8859-15
de_DE.UTF-8/UTF-8

Help! I Don't know what my Locales settings should be!

Don't worry, this is quite simple. The entries in the file are in the format <locale>/<charmap>. <locale> is a locale from the /usr/share/i18n/locales directory and <charmap> is the name of one of the files in /usr/share/i18n/charmaps/. Two things to note, locales with odd currencies, typically the euro, where the old currency (e.g. "Deutsche Mark") has been replaced by the euro require the @euro modification given in the example above The only thing to note is UTF-8 locales require you to add .UTF-8 to the end of them in order to work (No I don't know why, it shouldn't, but otherwise it breaks....)

If you REALLY want to minimise your locales then you should just switch to using unicode on your system. This is a bit more fuss, but as it is becoming the defacto standard it has many advantages to all the alternative (older) ISO, ASCII etc formats. Read more about this in UTF-8, Locales or this manual from the gentoo documentation site.

This allows you to specify just:

Pre glibc-2.3.6-r4 or glibc-2.4-r2, modify /etc/locale.build:

File: nano -w /etc/locale.build
#As before!
en_US.UTF-8/UTF-8
de_DE.UTF-8/UTF-8

As of glibc-2.3.6-r4 or glibc-2.4-r2, modify /etc/locale.gen, removing /etc/locales.build:

File: nano -w /etc/locale.gen
#As before!
en_US.UTF-8 UTF-8
de_DE.UTF-8 UTF-8

It is best to keep the US UTF-8 line in as some programs rely on it and compilation can fail if you remove it.

Doing this before a Gentoo Installation

You can set this up prior to building your system for the first time from scratch. Just follow the instructions at the gentoo handbook. This means you can worry less about cruft, and enjoy a quicker install.

Doing this after a Gentoo Install

Then glibc is already installed, so you need to remerge glibc:

Code: Remerging glibc
emerge --oneshot glibc

You can also re-emerge world if you are uber keen, to get rid of all those packages already compiled with a zillion language support, but the performance and space saving benefits are not probably worth it. Just let your system sort itself out over time, as packages are updated.

It might also be worth your while investigating reading Locales which can clean out any installed man-page or info-file in languages you don't need on your system.

This optimisation is entirely safe (unless you can't read the language you set!).

Security

Security, how's that an optimisation? Well it's a security optimisation, as I said before optimisation depends on your system and how you use it. If it is a server for example then you may want to optimize your system for security, instead of speed, or maybe even both.

Hardening Glibc

This relies on, (yes you've guessed it...) the hardened USE Flag. It makes your system less vulnerable to malicious attacks of various sorts.

Stack smashing

Uses the erandom flag, for which you need the erandom module installed in your Kernel.

Retrieved from "http://www.gentoo-wiki.info/Optimize_glibc"

Last modified: Fri, 12 Sep 2008 10:06:00 +0000 Hits: 25,704