The IBM Next-Generation POSIX Threading library is an LGPL POSIX threading library that implements a M:N threading model. This library brings Linux much closer to POSIX compliance where threading is concerned, and brings with it better performance. I would like to see use of NGPT added as an option during the Gentoo Linux stage1 build process, so all applications can be compiled to take advantage of this threading model. The kernel patches required to support NGPT have already been accepted into the 2.5 development tree as well as 2.4, as of 2.4.19-pre2
Just me, or they not in official 2.4.19 ? Also, last time I checked, nextgen threads broke some stuff. We did talk about this some time back (6 months ??), and will support it, but it needs a wider acceptance first (should definately be in 2.4 kernel for one).
Quoted from IBM's website: Kernel release 2.4.19 contains everything necessary to run NGPT and use of the patch is not required. and If you're running 2.4.19, apply the the patch-futex-2.4.19 patch. This patch only contains the extensions necessary for run NGPT 2.0 (the release of the kernel provides all the other necessary NGPT support by default, so a smaller patch is appropriate). NGPT has come a long way since 6 months ago. And as of 2.4.19pre2, the basic hooks for NGPT support *were* added into the 2.4 tree. NGPT 2.0 has some new extensions that haven't been added yet, but they probably will be for 2.4.20.
Ok, so I havent maybe really checked it out again :=) I still think to maintain stability, we should wait a bit, as something like this will need assurance that the kernel can handle it. Also, we are on a feature freeze for 1.4_rc release.
I can understand that, a change so late in 1.4's devel would be folly. Perhaps for 1.5? And I can also understand the need for stability, which is why I just wanted it to be something like a USE flag during bootstrapping, for people who decided they'd take the risk and try it. At bootstrap is the best time to add NGPT cause then all the applications compiled for the system will take advantage of it, and there won't be problems with applications that were linked against linuxthreads.
Thanks. Anyhow, I will see what I can do, as I wanted to try it out myself back then, but never got to it. Will not promise though, as I have my hands a bit full at the moment. After 1.4, I am sure we can really make a plan.
I gave it a shot, and most pthreads-enabled apps won't compile with it... We need to have patches for NGPT support before we can use it. I can put futexes in the kernel though.
on second thought, I realized that my problems were user error. it seems to work now. Fast!
Created attachment 4110 [details] glibc-2.2.5-r6.ebuild Ok, this *should* be a ebuild which added NGPT support. Some NOTES: 1) It is not a 100% drop in replacement for linuxthreads, so you still have to compile glibc with linuxthreads. I just tweaked it to already install ngpt to /lib 2) I don't think that you should install it, except during bootstrap (from scratch ..) .. segfaults, etc 3) If bootstrap, you need a NGPT enabled kernel on bootcd, or system with booted with a NGPT enabled kernel. 4) When doing the chroot, you have to do an additional 'mount --bind': # mount --bind /dev/shm /mnt/gentoo/dev/shm 5) When starting bootstrap, you have to do: # export FEATURES=-sandbox ; export USE=ngpt I suggest to also put that in make.conf. Like you would have noticed, I disable sandbox, as it once again is the root of all evil :( For some reason it causes things to segfault, although not all the time, and also at relatively consistant places.
Created attachment 4138 [details] glibc-2.2.5-r6.ebuild Ok, this is what I think we want. Basically this replaces linuxthreads totally with NGPT. Although we still need linuxthreads to get glibc to compile, even glibc links against libpthread from NGPT! Currently im busy with a 'emerge gnome' in a 100% NGPT chroot. To get it to work is the real hairy part, as most things that is linked against the old glibc with linuxthreads seems to 'hang' when we merge this glibc. I thus had to create a build image that is 90%-99% statically linked, and then start a bootstrap chrooted from there. Quick overview: 1) Create the static build image we are going to chroot into: # export ROOT=/var/tmp/build # FEATURES=-sandbox \ LDFLAGS=-static \ USE="ngpt -X -gnome -gtk -tcltk" \ emerge --nodeps --noreplace `/usr/portage/scripts/build.sh x86-1.4` Some stuff here like python needed attention. For instance python I merged without the 'LDFLAGS=-static'. 2) Now we need to cleanout /var/tmp/build/var/db/pkg/ a bit. We only want entries for: sys-kernel/linux-headers* sys-devel/binutils* sys-apps/baselayout* sys-libs/glibc* Very much like the secound build fase of creating stage1... 3) Chroot it, and do the normal 'source /etc/profile && env-update' 4) Fix the two things that either links to old libpthread, or should not be static: # FEATURES=-sandbox USE=build emerge --nodeps python bash NOTE: I had to use bash-2.05a here, as 2.05b needs autoconf ... 5) Do the bootstrap and emerge system. Note the following: a) You need to have "ngpt" in your USE. I created my own bootstrap.sh for this. b) Know that sandbox is going to bork. # export FEATURES=-sandbox # export USE=ngpt # /usr/portage/scripts/bootstrap.sh && emerge system Well, that is roughtly it. There is one or two other places build broke for me. I had to remerge db1 and db3 before perl worked for instance ...
Another note: '-pipe' in CFLAGS or CXXFLAGS can also cause issues...
someone forgot to add "addwrite /dev/shm/ngpt" to that ebuild..
Comment #10 from me .. disgard as I was on crack or something. As for comment #11, support have already been added to sandbox. Update: Most things seem to work fine with good performance, but the following issues occured/remain: 1) NGPT-2.0.2 caused make to "hang" if -j2 or greater was used. This is fixed in version 2.0.3. Compiling 'make' static also fixed this with 2.0.2. 2) db-3.2.9 compiles with unresolved symbols if anything linked dinamically to it do not link in libpthread, or if db itself was not compiled with LDFLAGS="-lpthread". Dont know how good an idea the second option is though. 3) Anything linked to librt.so.1 from glibc segfaults inside sandbox. 4) Anything that links dynamically to libGL* from nvidia-glx segfaults or "hangs". MPlayer for instance segfaults, while gliv, xmms and glxgears "hangs". If I delete the OpenGL plugins from xmms, it starts until the GUI appears, but then "hangs" again. 5) gcc-2.95.3 just do not compile. Anything that shows the "hang" symptoms have a lot of nanosleep() calls in the strace output. In general install seems to be ok now. You can do a normal bootstrap with this changed glibc ebuild and "ngpt" in use.
Created attachment 4301 [details] glibc-2.2.5-r6.ebuild Latest ebuild just for completeness.
I have tested, expensivily, ngpt with glibc-2.3 and the current version, 2.0.3, is not compatable with glibc-2.3. All programs using ngpt segfault on startup. I have sucessfully used ngpt with glibc-2.2.5 so it is not user error. On the topic, it seems the offical new (beta) threading library for glibc and linux is nptl 0.3, see http://sources.redhat.com/ml/libc-alpha/2002-10/msg00080.html and http://sources.redhat.com/ml/libc-alpha/2002-10/msg00160.html for more info. Should we use this instead when linux-2.6 is out?
To be honest .. I think ill wait for linuxthreads2 :/
Well I have been playing with nptl / linuxthreads2 for some time now, at the request of woodchip. It works very well with the 2.5.5x kernels. I have it installed on my desktop. Version 0.15 nptl is complete, according to the author, for x86. You also need the CVS version of glibc, which also is stable. Redhat has already taken the step of putting it into there beta, rawhide, distributions. We cannot be out done! The only problem is the kernel requirement. Redhat has back ported the thread changes to 2.4.20/21. The patch is fairly messy because it goes onto of a few other redhat patches. But I have completed patching 2.4.21-pre2 with o1-scheduler and the thread backport. The kernel now needs to be debuged by me, but it should be ok. What do you people think, would gentoo be interested, or do we wait for the official 2.6 kernel + glibc ( which could be a while yet) eventhough we can have it sooner.
I havent tried NGPT, bug I have an cvs ebuild for glibc here, with NPTL (cvs). It worked fine up to a week ago, but now anything using pthreads from NPTL segfaults. This was after a cvs update. Running 2.5.5[34] here btw. Stephan, if the 2.4 patches are stable, I do not see why not, if 2.3.2 hits the shelfs, but I think we need to test it first. According from what I can see from Redhats .spec's, they only consider NPTL stable/working for i686/athlon archs.
I had a similar problem when I tried a much older version... As I recall, my initial idea behind getting NGPT support into Gentoo was as a stageX compile option, but not default. something like a USE flag, with a warning that not everything may love it. Though, I'd love to see Gentoo adopt it as default. I haven't read much on linuxthreads2 though. I may have to go look at it.
At the moment nptl only exists for x86, it still has to be ported to other archs. So this for the time being will be x86 only. I think some archs will not be ported for some time (sparc + alpha) The trick to get nptl to compile is to use the glibc CVS on the day of the nptl release, ie for nptl-0.15 use cvs co -D "2003-01-05T20:19:00+0000" libc This is the version I use, it works fine, except for nvidia's libGL binaries. The kernel needs quite a bit of debuging, Ingo Molnar at redhat is working at it. My patched 2.4.21 kernel causes old glibc linuxthreads aplications to segfault. I have an idea where the problem is, will try to fix. The kernel runs nptl fine though.
Martin, Stefan Can you please post/email me your nptl ebuilds? I REALLY want to test it!
NGPT is at end of life - we have NPTL ebuilds that works.