The GNU C Library 2.44 was released on Saturday, July twenty fifth, and the change most sysadmins will feel is a new file: /etc/tunables.conf. Until now, setting a glibc tunable meant exporting GLIBC_TUNABLES into the environment of every process you wanted it to affect, which in practice meant editing systemd units one at a time or wrapping binaries in shell scripts. The new file lets you declare tunables once, one per line, with filters to scope them. The release also adds a tunable controlling transparent huge pages for read only executable segments, and imports faster math routines. We looked at what changes in day to day operations.
The short answer
The GNU C Library 2.44 arrived on Saturday, July twenty fifth. The operational change is /etc/tunables.conf, a system wide file for glibc tunables that replaces the need to push GLIBC_TUNABLES into the environment of every process. A new tunable controls transparent huge pages for read only executable segments, the cosh implementation gained roughly 35 percent through fused multiply add, and more correctly rounded math functions arrived from CORE-MATH. Expect it packaged in Ubuntu 26.10 and Fedora 45.
Anyone who has tried to set a glibc tunable across a fleet knows the shape of the problem. The setting itself is one line. Getting that line in front of every process that needs it is the work, and until this week the only supported route ran through the environment.
The file that fixes an old annoyance
glibc tunables let you adjust allocator behaviour, hardware capability selection and a handful of other internals without recompiling anything. They are genuinely useful, and they have always been slightly awkward to deploy, because the only interface was the GLIBC_TUNABLES environment variable. That variable has to be present in the environment of the process you want to affect, which on a modern Linux host means an Environment or EnvironmentFile line in a systemd unit, repeated for every service, and re added every time somebody writes a new one.
glibc 2.44 introduces /etc/tunables.conf. You write one tunable per line, and a range of filters and other options can be applied to control scope. Configuration management templates a file, ships it, and the setting is in effect for the system rather than for whichever units somebody remembered to edit.
The environment variable still works, which is the right call for a change like this. Nothing you have already deployed breaks. The migration that makes sense is to move your fleet wide defaults into the file, where they become visible to anyone reading the host's configuration, and keep the environment variable for genuine exceptions where one service needs to differ from everything around it.
Huge pages for code, not just data
The second change worth reading carefully is a tunable governing transparent huge pages for read only executable segments. The distinction matters. Huge page discussions usually concern the heap, where glibc has offered allocator side controls for some time. This one covers mapped executable code: your binaries and the shared libraries they pull in.
Backing hot code paths with two megabyte pages reduces instruction TLB pressure. On a binary with a large and widely spread instruction footprint, that translates into measurable throughput. Database engines, JIT compiled language runtimes and large monolithic services are the workloads where this shows up most clearly.
It ships as a tunable rather than a default because the benefit is workload dependent, and huge pages have historically been an area where a setting that helps one service does nothing for the next one. Treat it as something to benchmark on your own binaries, not something to enable fleet wide because a release note mentioned it.
The rest of the release
The math work continues a pattern glibc has kept up for several cycles. A fused multiply add implementation of cosh delivers roughly 35 percent improvement, and further optimised, correctly rounded functions arrive from the CORE-MATH project. Correctly rounded is doing real work in that sentence, because it means results are consistent rather than varying in the final bit between implementations, which is what makes numerical results reproducible across machines.
On the architecture side, 2.44 brings optimisations for LoongArch, AArch64 and RISC-V processors, and introduces support for LoongArch32, the thirty two bit variant. There is also a handful of security fixes, which is normal for a glibc release and is applied for you when the package updates.
What to do now
Very little, and that is the correct answer. glibc is the most conservative package in the distribution stack, and it reaches you when your vendor decides it should. Ubuntu 26.10 and Fedora 45 are the named targets for autumn. Enterprise distributions will be considerably behind that, which is a feature of those distributions rather than a fault.
The useful preparation is to know what the file is before it appears. If you currently carry glibc tunables in systemd units or wrapper scripts, write down which ones and why, because that inventory is what you will convert when 2.44 arrives on your images. Doing it now, while the reasons are still legible, is easier than reconstructing them from an Environment line eighteen months from now.
Sources and further reading
- LWN: GNU C Library 2.44 released
- Phoronix: GNU C Library 2.44 released with /etc/tunables.conf, more optimizations
- glibc project homepage and manual
- The CORE-MATH project
Frequently asked questions
What is /etc/tunables.conf and why does it matter?
It is a new configuration file in glibc 2.44 that holds glibc tunables system wide, one per line, with filters and other options available to scope which programs a setting applies to. Before this, the only supported way to set a tunable was the GLIBC_TUNABLES environment variable, which had to reach every process you wanted to affect. On a systemd host that meant an Environment line in each unit file, or a wrapper script around the binary. A single file that configuration management can template and drop in place is a much better fit for how fleets are actually managed.
Does the environment variable still work?
Yes. GLIBC_TUNABLES is not going away in this release, and the new file is described as an alternative rather than a replacement. That matters for migration, because it means you can adopt the file where it helps and leave working environment variable settings alone. The practical pattern is to move fleet wide defaults into the file, where they are visible and reviewable, and keep the environment variable for the one off cases where a single service genuinely needs different behaviour from everything else on the box.
What is the transparent huge pages change?
glibc 2.44 adds a tunable that controls whether transparent huge pages are used for read only executable segments, meaning the mapped code of your binaries and libraries rather than the heap. Backing hot code with two megabyte pages can reduce instruction TLB pressure, which shows up as a throughput gain on large binaries with wide instruction footprints, database engines and language runtimes being the classic cases. It is a tunable rather than a default because the benefit depends heavily on the workload, so measure it on your own binaries before rolling it out.
How much faster is the math in 2.44?
The headline figure is a fused multiply add implementation of cosh giving roughly a 35 percent improvement. The release also imports more optimised and correctly rounded math functions from the CORE-MATH project, continuing work that has been landing over several glibc cycles. Correctly rounded matters as much as fast here, because it means results are reproducible across implementations rather than varying in the last bit. If your workload is numerical, this is a free gain that arrives with a routine library update.
When will I actually get glibc 2.44?
Through your distribution, on its own schedule. Ubuntu 26.10 and Fedora 45 are the two named targets for autumn 2026. Enterprise distributions with long support cycles will be considerably later, since glibc is the single most conservative package in the stack and rebasing it mid release is not something vendors do lightly. Nobody should be building glibc from source on a production host to get a tunable file early. Note the features now, and plan for them when the packaged version lands.