# LinuxThreads & NPTL

## snail0r

How could one change so that the default threads implementation uses the more recent NPTL rather than LinuxThreads?

----------

## Schwinni

You need to set the USE flag "nptl" in your make.conf.

If you want to use only nptl you also have to set "nptlonly" (all programs which are "emerged" should work).

After that make an "emerge --newuse world" and glibc will be rebuilt.

Attention: If you do NOT use nptlonly your glibc will be built twice, once with nptl and once with linuxthreads.

Greetz,

Schwinni

----------

## snail0r

Great stuff. Thank you very much for your prompt answer. About to thread my FTP-client and would rather make use of the NPTL instead of LinuxThreads. This solved my problem, thank you!

----------

## depontius

 *Schwinni wrote:*   

> You need to set the USE flag "nptl" in your make.conf.
> 
> If you want to use only nptl you also have to set "nptlonly" (all programs which are "emerged" should work).
> 
> After that make an "emerge --newuse world" and glibc will be rebuilt.
> ...

 

Is there a downside to using nptlonly? I've been using nptl for some time, and just tonight there's another glibc out, which is a real pain since it gets buit twice. (nptl and linuxthreads) This would be on both x86 and x86_64.

----------

## Schwinni

Well, I didn't see a program which didn't work with "nptlonly".

Like I said, all programs in portage should work.

I would give it a try. I you see a program which only runs with linuxthreads you still can delete "nptlonly" and rebuild glibc.

Greetz,

Schwinni

----------

## yabbadabbadont

I was using nptl and when I saw the glibc update, added nptlonly.  After glibc was updated, I did an emerge -e world.  I have portage logging turned on and there weren't any problems listed in the logs.  Everything seems to work fine.

----------

## depontius

 *yabbadabbadont wrote:*   

> I was using nptl and when I saw the glibc update, added nptlonly.  After glibc was updated, I did an emerge -e world.  I have portage logging turned on and there weren't any problems listed in the logs.  Everything seems to work fine.

 

Thinking a little more, would I really need to "emerge -e world" or could after adding USE="... nptlonly" could I just "emerge glibc" and then "emerge -N world" to only rebuild the stuff that had threading in the first place?

----------

## yabbadabbadont

If that would only get the stuff that uses threading, then great.  I didn't know if it would or not, so I just rebuilt everything.  Does anyone have a definitive answer?

----------

## rhill

 *depontius wrote:*   

> Is there a downside to using nptlonly?

 

nope.  in fact linuxthreads support was completely dropped from glibc after 2.3.5.

 *depontius wrote:*   

> Thinking a little more, would I really need to "emerge -e world" or could after adding USE="... nptlonly" could I just "emerge glibc" and then "emerge -N world" to only rebuild the stuff that had threading in the first place?

 

you have to rebuild everything.  the only thing that would have a different USE flag would be glibc, so using -N wouldn't pickup anything but it.

actually i don't think you need to rebuild everything, but i've never migrated from linuxthreads so i don't know for sure.  start with the toolchain anyways - linux-headers, glibc, binutils, and gcc in that order.

----------

## Sachankara

 *dirtyepic wrote:*   

>  *depontius wrote:*   Is there a downside to using nptlonly? 
> 
> nope.  in fact linuxthreads support was completely dropped from glibc after 2.3.5.

 w00t? What about those who use i386 or i486 profiles then? NPTL only works with i586 or higher...

Not that it affects me, but still... Are you sure?

----------

## depontius

Last night I did 'USE="-threads" emerge -tuvDN world' to see what would be flagged in terms of having anything to do with threads. Then I rebuilt glibc, tcl, and tk with the nptl and nptlonly flags. The system works just fine, but it sounds like I really ought to rebuild the toolchain, then pick a convenient time to "emerge -e world".

----------

## Schwinni

As I switched from linuxthreads to nptl on my notebook, I dind't recompile everything.

After changing the use flags I only did an "emerge -N world".

glibc was rebuild and everything was fine.

I don't think there's the need to do an "emerge -e world".

Greetz,

Schwinni

----------

## depontius

Well, it's running now. It'll be done tomorrow morning, so at this point, I'm just going to let it finish out. I think I'll take your advice on my slower machines, though.

----------

## rhill

 *Sachankara wrote:*   

>  *dirtyepic wrote:*    *depontius wrote:*   Is there a downside to using nptlonly? 
> 
> nope.  in fact linuxthreads support was completely dropped from glibc after 2.3.5. w00t? What about those who use i386 or i486 profiles then? NPTL only works with i586 or higher...
> 
> Not that it affects me, but still... Are you sure?

 

here's the removal announcement:

http://sources.redhat.com/ml/libc-alpha/2005-07/msg00001.html

----------

## depontius

But that's 2.4, and current stable is 2.3.5-r2, so most of use haven't seen it, yet.

Incidentally, last night's "emerge -e world" didn't go well on either machine. I'd done it under a nohup on the amd64 machine, and it "stopped" somewhere in ./configure on one package, testing SIG(mumble). At this point, the nvidia kernel module won't load, even after a rebuild, so I'm doing "emerge -e world" from a console. Hopefully this evening it will straighten out. Either that, or on ams64 nvidia-kernel is doesn't like nptlonly. I don't have time now, but will search that later today. On this AthlonXP machine, I ran out of disk space. I cleared off enough to keep the machine running, and it's in decent order. At some point, I'm going to "emerge -C doom3-demo" and then retry the world. But I think I'll wait until I have the amd64 running properly, first.

----------

## Gentree

since almost everything depends on glibc I would have expected to need to at least relink any binaries (and rebuild most of the rest to be sure to keep the system stable unless you can be sure that nothing uses the old thread model).

Otherwise you can trust "well I tried it last night and it seems fine" , but I would like to base my maintainance on something a bit more solid.

I dont claim a thorough understanding so I prefer to risk doing some possibly unnecessary compiling than having headaches pop up on the day I dont have time to untangle a mess.

 :Cool: 

----------

## Paapaa

It would be really nice to hear from developers the answer to this:

If I start using NPTL using "USE=nptlonly", do I have to recompile EVERYTHING with "emerge -e world" or is "emerge -uDN world" enough? The latter basically recompiles only glibc.

----------

## Ma3oxuct

 *depontius wrote:*   

> At this point, the nvidia kernel module won't load, even after a rebuild, so I'm doing "emerge -e world" from a console. Hopefully this evening it will straighten out. Either that, or on ams64 nvidia-kernel is doesn't like nptlonly.

 

I think that this is true. Nvidia does not use NPTL, but rather linuxthreads. If you compile an nptlonly system do no expect to be able to have nvidia's 3D acceleration.

----------

## Gentree

```
bash-3.00#glxgears

4306 frames in 5.0 seconds = 861.200 FPS

4641 frames in 5.0 seconds = 928.200 FPS

4629 frames in 5.0 seconds = 925.800 FPS

4643 frames in 5.0 seconds = 928.600 FPS

4613 frames in 5.0 seconds = 922.600 FPS

4636 frames in 5.0 seconds = 927.200 FPS

4641 frames in 5.0 seconds = 928.200 FPS

```

```
bash-3.00#glxinfo

name of display: :0.0

display: :0  screen: 0

direct rendering: Yes

server glx vendor string: NVIDIA Corporation

server glx version string: 1.3

server glx extensions:

    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 

    GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control

client glx vendor string: NVIDIA Corporation

client glx version string: 1.3

client glx extensions:

    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, 

    GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, 

    GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 

    GLX_SGI_swap_control, GLX_NV_float_buffer

GLX extensions:

    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 

    GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, 

    GLX_ARB_get_proc_address

OpenGL vendor string: NVIDIA Corporation

OpenGL renderer string: GeForce2 MX/AGP/SSE/3DNOW!

OpenGL version string: 1.5.2 NVIDIA 66.29

OpenGL extensions:

.............

```

seems accelerated enough for a GF2   :Very Happy: 

USE="nptl nptlonly  usb X opengl svga tiff jpeg png mng gif imlib ....

on athlon-xp , not 64.  :Cool: 

----------

## JuddRogers

I ran

```

find . -type f -name \*ebuild | xargs grep -i ntpl

```

and got just sys-libs/glibc

```

emerge -p -u --deep --newuse world

```

per the Gentoo Handbook produces a whole raft of packages to compile but most are updates, not recompiles.

```

emerge -p --deep --newuse world

```

lists just the recompiles. That might be a good way to go.

 *Schwinni wrote:*   

> As I switched from linuxthreads to nptl on my notebook, I dind't recompile everything.
> 
> ...

 

----------

## depontius

 *Ma3oxuct wrote:*   

>  *depontius wrote:*   At this point, the nvidia kernel module won't load, even after a rebuild, so I'm doing "emerge -e world" from a console. Hopefully this evening it will straighten out. Either that, or on ams64 nvidia-kernel is doesn't like nptlonly. 
> 
> I think that this is true. Nvidia does not use NPTL, but rather linuxthreads. If you compile an nptlonly system do no expect to be able to have nvidia's 3D acceleration.

 

This machine is fully operational, again. I ended up changing over to kernel alsa instead of alsa-drivers, but nvidia works just fine with nptlonly.

Next I'm going to go straight udev, without the tarball. Actually, I think I'll clean up the Athlon XP for nptlonly, first.

----------

## Gentoo User

Hello there!

I am also thinking of switching to NPTL but do not know if it's worth doing. Would you please post how it goes on your machines. Have your systems gained any noticeable performance boost or become more stable? How can the promised effectiveness be observed? Thanks for your kind attention.

Rgds

Gentoo User

----------

## Gentree

Well I never notice a massive difference that slapped me in the face and I never bothered doing serious bench testing. It's reportedly better by those who are in the guts of it and it is the way it will be in the future. So I guess , do it now or do it later.

 :Cool: 

----------

## Gentoo User

Hello there!

Thanks for your comment. 

Yes, I will do it in the near future. Hopefully, my system won't crash  :Smile:  .

Rgds

Gentoo User

----------

## Paapaa

I have not witnessed any noticable performance boost - even if it is there. The main advantage is that "top" shows now only processes, not multiple threads of a single process. Now I don't see 5 firefox-bins there which all are the same process. That is an advantage - albeit small.

Also, I got information from #gentoo, that you DON'T have to compile everything. Just compile with "emerge -uDN world" and things will start use NPTL.

And finally: using "nptlonly" for glibc is safe if you don't install programs outside portage. If you don't specify nptlonly, glibc is compliled twice: with linuxthreads and with NPTL. That will maximize compatibility.

----------

## i92guboj

 *Ma3oxuct wrote:*   

>  *depontius wrote:*   At this point, the nvidia kernel module won't load, even after a rebuild, so I'm doing "emerge -e world" from a console. Hopefully this evening it will straighten out. Either that, or on ams64 nvidia-kernel is doesn't like nptlonly. 
> 
> I think that this is true. Nvidia does not use NPTL, but rather linuxthreads. If you compile an nptlonly system do no expect to be able to have nvidia's 3D acceleration.

 

Are you sure  :Question: 

```

[ /etc/portage ]-[2]: /lib/libc-2.3.5.so

GNU C Library stable release version 2.3.5, by Roland McGrath et al.

Copyright (C) 2005 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.

Compiled by GNU CC version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8).

Compiled on a Linux 2.6.11 system on 2005-10-06.

Available extensions:

        GNU libio by Per Bothner

        crypt add-on version 2.1 by Michael Glad and others

        Native POSIX Threads Library by Ulrich Drepper et al

        The C stubs add-on version 2.1.2.

        GNU Libidn by Simon Josefsson

        BIND-8.2.3-T5B

        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk

Thread-local storage support included.

For bug reporting instructions, please see:

<http://www.gnu.org/software/libc/bugs.html>.

[ /etc/portage ]-[0]: glxinfo

name of display: :0.0

display: :0  screen: 0

direct rendering: Yes

server glx vendor string: NVIDIA Corporation

server glx version string: 1.3

server glx extensions:

    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,

    GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control

client glx vendor string: NVIDIA Corporation

client glx version string: 1.3

client glx extensions:

    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info,

    GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync,

    GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,

    GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float

GLX extensions:

    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,

    GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control,

    GLX_ARB_get_proc_address

OpenGL vendor string: NVIDIA Corporation

OpenGL renderer string: GeForce2 MX/AGP/SSE/3DNOW!

OpenGL version string: 1.5.3 NVIDIA 76.76    

```

Nptlonly since first install.

----------

## Sachankara

 *Paapaa wrote:*   

> I have not witnessed any noticable performance boost - even if it is there. 

 Try running something thread intensive, like running a web server and handle 20 000 concurrent threads -- then you'll see what NPTL is capable of...  :Smile: 

----------

## nxsty

 *Ma3oxuct wrote:*   

>  *depontius wrote:*   At this point, the nvidia kernel module won't load, even after a rebuild, so I'm doing "emerge -e world" from a console. Hopefully this evening it will straighten out. Either that, or on ams64 nvidia-kernel is doesn't like nptlonly. 
> 
> I think that this is true. Nvidia does not use NPTL, but rather linuxthreads. If you compile an nptlonly system do no expect to be able to have nvidia's 3D acceleration.

 

Very old versions of nvidia's drivers (around 2003) had problems with NPTL but that was fixed and hasn't been a problem since. I'v been using nptl and nptlonly without any problems with nvidia's drivers and hardware acceleration works perfectly.

----------

## depontius

I eventually got to nptl and nptlonly with no lasting problems, just some growing pains getting there. (On this machine, that is. I still need a round tuit to finish the build on the kids' machine.)

My numbers for glxgears went up slightly (5%) with nptlonly.

----------

