Slackware’s latest -current tree now includes a version of the kernel that supports NPTL, resulting in a dramatic performance boost.
Slackware Gets NPTL
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
About time! I thought NPTL was standard in all distros since over a year ago.
About time! I thought NPTL was standard in all distros since over a year ago.
Yeah, I was going to post something about Patrick putting the “slack” into “Slackware”, but then I recalled all the health problems he’s had over the past year, so I guess he has a pretty good excuse taking a while to add NTPL support.
>… blah blah … add NTPL support.
… and NPTL support too.
What is NTPL and how does it result in a performance boost?
It’s a new threading library. It’s been around for a while in RedHat/Fedora, and was backported even into the 2.4 kernels for those distributions. Gentoo doesn’t have it, although there are directions for installing NPTL.
I see that PV also upgraded the kernel in -current to 2.6.11.9 — is that the first time kernel 2.6.x has been in -current? I run 10.1 and compiled my own 2.6.11.8, and I know he put 2.6.10 in /testing for 10.1, but I don’t recall seeing 2.6.x in -current before (although I have not been watching too closely lately).
Gentoo doesn’t “have it” or “not have it”, if you are using a 2.6 kernel (which is default for x86 at least), you can set the nptl use flag and glibc will be built with it. now, the stage3 tarball doesnt have it, but saying it “doesnt have it” is misleading.
It’s a new threading library. It’s been around for a while in RedHat/Fedora, and was backported even into the 2.4 kernels for those distributions. Gentoo doesn’t have it, although there are directions for installing NPTL.
Just wanted to clarify this
. I’m using Gentoo with nptl right now, while that may be used by default if you do no configuration during the install (stupid idea).
You just have to specify that you want to use it in your /etc/make.conf by adding “nptl” to your USE flags, which the Gentoo Handbook teaches you about if you read it to install Gentoo (for new users this is very important). Once you put it in your use flags, you can just emerge (compile and install) glibc like normal.
How you would check if it’s enabled:
$ emerge -pv glibc
These are the packages that I would merge, in order:
Calculating dependencies …done!
[ebuild R ] sys-libs/glibc-2.3.5 -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck +nptl -nptlonly +pic +userlocales 0 kB
The words after the package name are the use flags that are enabled. And emphasis added for nptl.
The more you know
Especially if he’s adding things that have been in other distros for ages… When is he going to add Pam?
He’ll add it once Pam is obsolete
In 2004.3, it was a little trickier than what you’ve posted, as you needed to fidget around with with linux26-headers, but there are instructions for it, and they’re not too difficult.
http://gentoo-wiki.com/NPTL
2005.0 seems to have resolved that, but I’ve not tried it.
http://forums.gentoo.org/viewtopic-t-319349.html
I’m using Gentoo with nptl right now, while that may be used by default if you do no configuration during the install (stupid idea).
Why is that a stupid idea?
Read the Changelog (or the link above). Kernel 2.6 is still in /testing.
So has anyone actually upgraded to the new slack glic? Any notable problems or improvements?
Why is that a stupid idea?
Well, it’s always a good idea to read up on the documentation of your operating system
. And also because the gentoo handbook encourages you to. Part of the strength of gentoo is that you can configure it to your liking, and it’s a shame not to take advantage of it’s unique features (like USE flags). However, there’s nothing stopping you from leaving things relatively near the defaults. Just know what you’re doing, in either case 
.
OK, just seeing if that was one of those “optimize” arguments
I used some benchmarks on MySQL with and without NPTL on Gentoo 2004.3, and I didn’t see any performance difference one way or the other.
It’s my understanding that you won’t see many performance improvements unless your app is creating and destroying thousands and thousands of threads. Joe-average app probably won’t notice a difference. The only reason I cared about it is because Mono’s debugger needs an NPTL-enabled glibc.
Before NPTL, there was linuxthreads. This is misleading, because linuxthreads aren’t really threads, they’re just lightweight processes. And they aren’t POSIX compliant either. Using POSIX threading semantics and signal passing with linuxthreads is a can of worms to say the least, and results in way too much processor time being spent remapping virtual memory and creating/destroying threads. Posts on the LKML indicate that the average thread_create() call with NPTL is 8 times faster than with linuxthreads. Linuxthreads were tacked on to glibc to allow applications that require threading to perform on the right order of magnitude (proxy and routing services come to mind as early examples) to run on linux. They were not meant to be an elegant or ideal solution (read: dirty hack).
NPTL is the second attempt (first was NPGT) to have real POSIX threading on Linux. The process can be as simple as rebuilding glibc with the proper configure flag, although you probably want to build both NPTL and linuxthreads into glibc so that any packages that don’t work properly with NPTL can still use linuxthreads. I’m not sure how many packages this affects, because Gentoo kindly hides this complexity.
Speaking of which, I can confirm that with Gentoo 2005.0 you no longer need to edit your package virtuals to get glibc to link against the 2.6 kernel headers. Users who installed with previous releases won’t have a problem either, as long as you followed the simple instructions for linking to the new 2005.0 profile that resulted the last time you synced your portage tree. I was made aware of a new experimental stage 3 release that is built with NPTL, but this isn’t really necessary. I just install from stage 3 (after my 5th or 6th gentoo install I realized that the earlier stages are for those with either esoteric hardware or even more esoteric personalities), set my USE and CFLAGS according to my religious affiliations, and realize that since the stage is out of date anyway, most packages will be rebuilt within several weeks of periodic updates. Before you know it, you’ll have a pure NPTL system with the simple addition of four characters to your make.conf file.
Actually, you won’t have a pure NPTL system unless you also use the nptlonly USE flag, but I don’t do this and I don’t know if it breaks anything of note.
Of course, there is a bit of magic speed increases to be realized now and much more to be realized some time in the future. Unfortunately, not all software makes full use of threading. As the goals of hardware optimization switch gears from instruction level parallelism to thread level parallelism, one can only hope that the software industry (and in particular the free software universe) can keep up.
erm..
/etc/make.conf doesn’t exist
> How you would check if it’s enabled:
> $ emerge -pv glibc
Same there… =/
I’m a bit puzzled about this. I thought that NPTL was included in 2.6 vanilla so any distrib with 2.6 was “NPTL compatible”. Is it the case ? I know that Mdk from 10.0 is “NPTL enabled” but if I’m compiling a 2.6 kernel from kernel.org will I have NPTL ?
My reasons for asking is that for anyone using Java based application (like eclipse), NPTL is a MUST (x2 at least, see http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html for more details).
I have two linux configurations (home/work), both are based on Mdk 10.1. Home conf has a re-compiled kernel from mandrake patched 2.6.8 sources. Work is also a recompiled kernel but 2.6.11 from kernel.org. All conf specs are the same (ram, disk, etc..). Result is a home conf far quicker that the work one.
So any idea to have a clear idea about that would be appreciate.
You do have Gentoo?
I think corporates if there is any running this great os should give slackware a chance to power their servers,etc.
My reasons for asking is that for anyone using Java based application (like eclipse), NPTL is a MUST (x2 at least, see http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html for more details).
I read through the link (rather quickly though…), I don’t think it stated as a must. In fact, it even gave a performace comparison between Java with and without NPTL (this implied Java can be executed in both environment) here:
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html#12
I have been using Slackare ever since I started playing with Linux. I never have any problem running Java Applications (either in house built or download from somewhere else). But with this new update, I think the Java applications will run much better in Slack.
I beleive Pat does not wish to add PAM as he beleives it to be “riddled with security holes”*.
*see:alt.os.linux.slackware FAQ
So has anyone actually upgraded to the new slack glic? Any notable problems or improvements?
Just downloaded and upgrade my Slack with -current. Honestly, I don’t really feel any diff.
No problem so far (after more than an hour of usage).
Using Slackware 10.1 + Dropline GNOME.
I don’t think you have to configure anything in a 2.6 kernel to get NPTL. But you need a NPTL-enabled glibc for apps to use it.
So has anyone actually upgraded to the new slack glic?
Yes. Two things:
* The NVidia driver needs reinstallation.
* With the NVidia drivers a bug surfaces with XMMS, making installation of libmikmod mandatory.
Any notable problems or improvements?
My machine is practically idling all day
, maybe I should throw some Java programs at it.
How can I check if my linux distro is using NPTL ?
getconf GNU_LIBPTHREAD_VERSION
I use “nptlonly nptl” in my USE flags on Gentoo. No problems that I can attribute to it so far. For those who might be curious.
Before NPTL, there was linuxthreads. This is misleading, because linuxthreads aren’t really threads, they’re just lightweight processes (…)
Oh, but we all had to hear how much better this was than having real threads, and that the linux solutionw as superioe to every other OS’s threading model, und so weiter, und so weiter.
Oh, but we all had to hear how much better this was than having real threads, and that the linux solutionw as superioe to every other OS’s threading model, und so weiter, und so weiter.
This is the old 1:1 vs M:N discussion. Linux is 1:1 with NTPL, so is Solaris 10. BSDs and other OSes go for M:N because they think it’s better. In linux we really like 1:1, as we thin it’s better. See http://lkml.org/lkml/mbox/2002/9/24/33 for more details
NPTL makes the greatest difference in java apps. I couldn’t even run azureus on my laptop until I had an nptl enabled glibc. I have been using nptl on Gentoo for a while now. In fact, originally you did not have the option to build both linuxthreads and nptl versions of glibc, yet I never had a problem with a pure nptl setup. Now Gentoo gives you the option to use both, or only one, which was actually a little confusing for me at first when glibc started taking twice as long to compile.
“About time!”
I’m reading this kind of comment more and more often and, sincerely, it’s getting annoying. I wish there was a filter for the “Finally!” comments. They are spread in all kind of news where a distro adds a new feature. It’s a free project, man, and usually that means the developer spends his/her free time coding without expecting a profit.
I can’t recall where I read this from, but I remember it went something like this:
”
Coding and making features available to a free project was a lot of fun years ago, and usually one could expect a “Thank you” from the community. Now all you can get is a “Finally!”. It’s not fun anymore.
”
Patrick, you have created a very nice distro. Keep up with the good work. I really appreciate it.
You could always install it yourself, its a very trivial task. Slackware has never been about holding someones hand in getting things done.
Maybe so, but Slack is still considered one of the “top” (or at least most used) distros. The Linux distro world has changed from “thanks for adding this” to a competitive market. If Slackware was one of a million of the other distros nobody cares about, then I could care less if they used linuxthreads forever.
But, since Slackware still makes news on OSnews, it seems like it should try to keep up with the curve, especially when “adding support” means compiling glibc with a different configure option and using a 2.6 kernel.
(and yes I realize people can do this on their own, but we don’t read distro reviews on a “hey guys I recompiled everything in SuSE on my own so it’s completely not-stock and I think SuSE is great now!” basis)
FreeBSD has both 1:1 and M:N threading libraries (libthr and libpthread respectively, the latter was formerly known as libkse – kse as kernel scheduling entities). Currently most of the work is focused on the 1:1 libthr, but libpthread is the default.
This is an old post, but still very informative:
http://slashdot.org/comments.pl?sid=95211&cid=8187733
Its actually quite impressive that slackware is in the top-10 active distros. Not just because of its age but because its done by one guy, not a team or company like all the other 9 distros at the top. Yes, I know there are other ppl involved but they usually are providing bug fixes and pointing out errors. Now if we also take into account that Pat was sick for like 4 months in the end of 2004, during which time no major work was done (besides security updates by ppl he trusted), I totally understand that its taken this long for him to add in NPTL.
Hell, if it wasn’t for slackware, I wouldn’t be using linux today. I’d still be on freebsd, solaris and irix on all my boxes.
Maybe he just thouhgt it was getting stable enough to include in the next release of Slack. Thats what I like about Slack, stability first.
<Flame>Is nice to see how gentoo fans out there can convert any update on any other linux distro into “OK, gentoo got this first, and I’m happy I compiled it last year in my box”. C’mon people, if I made a linux from scratch, I could have this since day 1. Who cares about your experiences with gentoo? I just want to know how well it works on Slackware!!!</Flame>
OK, flame mode off: did anyone make another benchmark using ‘normal’ applications or server software? It would be nice to see if making an update would help me in normal desktop/development use.
Hi guys, I’ve been a long time slackware user, but I’m now thinking of making the switch, my reason being that I want an optimized linux without having to compile a whole bunch of things over again.
I sat through all the wars such as which distro has the better packaging system, or which distro has the best installer, but now that the dust has somewhat settled, I want to pick up a linux with some advanced kernel features without having to configure much. I hate having to compile crap, I hate rpm, I like the install system on slackware, but I don’t know if slackware has been optimized as well as it should, granted patrick was out with ailments for awhile.
I want some clustering services for high availability and load balancing, I definitely want the native posix threads library, and I want stability (is that too much to ask for, lol). Red Hat seems very unstable to me, the RHEL release anyway.
I was recently at the novell brainshare event and was starting to like how suse’s been shaping up.
So which distros have at least NPTL built in by default?
Sorry for cross posting, perhaps eugenia, you could give me my own article post, I guarantee lots of activity ;P
SUSE 9.3 comes with NPTL by default.
$getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.4
Dropline includes pam, and is an easy way to get it on slack. But for that, Dropline isn’t considered ‘pure’ slackware. If Pat includes it, there goes the main reason for animosity towards Dropline is eliminated.