# nptl? ja oder nein?

## makukasutota

Hallo Leute,

da ich inmoment von Windows zurück zu Gentoo wechsle und ich nicht so auf dem aktuellsten Stand bin habe ich da mal eine Frage. Überall lese ich inmoment von NPTL. Soweit ich bis jetzt herausgefunden habe scheint es eine Thread Library zu sein. Es scheint so ähnlich wie udev zu devfs ein Nachfolger von irgendner kernel-library zu sein. Stimmt das? Sollte man als ganz normaler Desktop-User darauf wechseln oder ist es eher was spezielles für die Leute die sich (mehr) auskennen und es "brauchen"? Ich hab bis jetzt per Google + Forum Suche nicht viel darüber gefunden, nur eine Menge Probleme damit.. Hoffentlich ist es keine total dumme Frage  :Confused: 

Danke für Hilfe,

maku

----------

## Deever

Äh, Threads gehören in modernen Systemen zum Standardumfang und sind wohl das einzige, was Windous UNIX jemals voraushatte...

Gruß,

/dev

----------

## schotter

wenn du doom3 spielen willst, brauchst du's

----------

## Sonic Lux

ntpl = nierentransplantation  :Very Happy: 

nptl = http://www.linux-mips.org/wiki/index.php/NPTL  :Confused: 

----------

## Mindphaser

Für Doom3 brauchst du es nicht, hauptsächlich verschnellert es das starten/beenden von Programmen.

Vorraussetung ist, das die jenigen Programme mit nptl-Unterstützung compiliert sind.

Dazu fügst du "nptl" und "nptlonly" zu deiner USE hinzu, emerge`st "glibc" neu, und jedes Paket was du ab dann emergen/compilieren tust nutzt nptl.

Achja, das du nen 2.6er Kernel fährst ist Grundvorraussetzung für nptl, sag ich nur mal so zur Sicherheit  :Smile: 

----------

## Der P@te

Reicht denn nicht nur nptl in den USE Variablen?

----------

## Sonic Lux

Laut http://gentoo-portage.com/s?search=use%3Dnptlonly ist nptlonly für glibc zuständig.

Merke gerade das ich es gar nicht in meinen use-flags drin hab   :Rolling Eyes: 

so nun nun emerge --newuse world feuer frei  :Very Happy: 

----------

## tuxian

Gibts irgendwo Benchmarks von System mit und ohne nptl?

----------

## Sonic Lux

```

bash-2.05b# emerge -uDp --newuse system

These are the packages that I would merge, in order:

Calculating system dependencies ...done!

[blocks B     ] sys-kernel/linux-headers (from pkg sys-kernel/linux26-headers-2.6.8.1-r1)

[ebuild  N    ] sys-kernel/linux26-headers-2.6.8.1-r1

[ebuild   R   ] sys-libs/glibc-2.3.4.20040808-r1

[ebuild     U ] app-arch/gzip-1.3.5-r4 [1.3.5-r3]

[ebuild   R   ] net-misc/wget-1.9-r2

[ebuild   R   ] net-misc/openssh-3.8.1_p1-r1

```

Wie bekomm ich den Bock weg ?

----------

## Mindphaser

Das "nptlonly" sagt nur, das glibc NUR für nptl compiliert wird, ansonsten hast du glibc dann quasi doppelt drauf, einmal für nptl und einmal für das alte threading zeuch. Natürlich braucht man nptlonly nicht gleich in die make.conf reinklatschen, nur weils von ein Paket genuzt wird... aber da es nicht stört tu ichs schon rein, damit nicht jedes mal wenn man glibc merged (z.B. wegen nem Update) ich dran denken muss "ahh, glibc, also USE="nptlonly" vorschreiben"  :Smile: 

Wegen den Block: Mhhhh also... vielleicht hast du "linux-headers" noch drauf ? 

Wenn ja, unmerge das mal. Ansonsten fällt mir jetzt auch nichts dazu ein. Wenn bis-du-das-hier-liest noch keiner ne Lösung für hatte, poste mal was "emerge -uDpt --newuse system" sagt.

----------

## Sonic Lux

Ich werde es mal probieren indem ich die linux header unmerge,

aber hier erstmal das geforderte:

```

bash-2.05b# emerge -uDpt --newuse system

These are the packages that I would merge, in reverse order:

Calculating system dependencies ...done!

[blocks B     ] sys-kernel/linux-headers (from pkg sys-kernel/linux26-headers-2.6.8.1-r1)

[ebuild   R   ] net-misc/openssh-3.8.1_p1-r1

[ebuild   R   ] net-misc/wget-1.9-r2

[ebuild     U ] app-arch/gzip-1.3.5-r4 [1.3.5-r3]

[nomerge      ] app-arch/bzip2-1.0.2-r3

[ebuild   R   ]  sys-libs/glibc-2.3.4.20040808-r1

[ebuild  N    ]   sys-kernel/linux26-headers-2.6.8.1-r1

```

----------

## chrib

 *Mindphaser wrote:*   

> Natürlich braucht man nptlonly nicht gleich in die make.conf reinklatschen, nur weils von ein Paket genuzt wird... aber da es nicht stört tu ichs schon rein, damit nicht jedes mal wenn man glibc merged (z.B. wegen nem Update) ich dran denken muss "ahh, glibc, also USE="nptlonly" vorschreiben" 
> 
> 

 

Für solche Fälle empfiehlt sich auch das nutzen von /etc/portage/package.use.

Gruß

Christian

----------

## Sonic Lux

Ein unmergen der kernel haeder hat nix gebracht, ich kann immer noch nicht mein system updaten.

Weiß jemand Rat ?

Sonic

----------

## hirnstrudel.de

vor dem update die 2.6 header emergen

----------

## hoschi

da stehts einwandfrei erklärt, sollte gehen  :Smile: 

viel spass

http://gentoo-wiki.com/HOWTO_Gentoo_2004.2_for_linux_2.6_and_NPTL#Getting_NPTL_to_work_on_already-running_systems

----------

## tuxian

Muss ich nur glibc neu kompilieren?

Wenn ich "nptlonly" in die /etc/make.conf schreibe ändert sich nichts an den USE-Flags, bei "nptl" hingegen schon.

----------

## mrsteven

Was mich wundert: Ich lese überall von diesem ominösen nptlonly-Flag. Ich habe vor einem Monat auf NPTL umgestellt, also:

```
emerge -C linux-headers

emerge linux26-headers

ufed #nptl aktiviert, nptlonly aber nicht

emerge --oneshot glibc
```

Und es hat gleich funktioniert: Ich habe xmms gestartet, und anstatt dass mir immer 6 Prozesse dafür angezeigt werden, kam nur noch einer. Also funktioniert es. Ich habe aber in der Doku gelesen, dass man noch ein "emerge -e world" machen sollte. Das war aber bei mir anscheinend gar nicht nötig...  :Confused: 

Wäre nett, wenn mich jemand aufklären könnte.

----------

## b3rT

 *tuxian wrote:*   

> Muss ich nur glibc neu kompilieren?
> 
> Wenn ich "nptlonly" in die /etc/make.conf schreibe ändert sich nichts an den USE-Flags, bei "nptl" hingegen schon.

 

das useflag gibt es schon, jedoch erst ab dem unstable glibc-2.3.4-20041102

----------

## Mindphaser

 *mrsteven wrote:*   

> Was mich wundert: Ich lese überall von diesem ominösen nptlonly-Flag. Ich habe vor einem Monat auf NPTL umgestellt, also:
> 
> ```
> emerge -C linux-headers
> 
> ...

 

Ein "emerge -e world" ist auch kein muss, dadurch werden halt nur ALLE Pakete neu compiliert, so das diese auch nptl nutzen, und das möchte man ja  :Wink: 

Das dein xmms nur noch ein Prozess anzeigt hat damit nichts zu tun, bei mir ist der Grosteil des Systems schon nptl "konform" und ich sehe immernoch viele Programme die mehrere Prozesse brauchen :-/

Was das nptlonly bring, habe ich weiter oben schonmal erläutert, es ist kein MUSS, aber wozu glibc zwei mal draufhaben, wenn man nur die nptl Variante braucht ?

Man kann auch mal in die .ebuild von glibc schaun, da sieht man ja das gibc diesen USE flag nutzt und wozu  :Smile: 

----------

## Mindphaser

 *b3rT wrote:*   

> 
> 
> das useflag gibt es schon, jedoch erst ab dem unstable glibc-2.3.4-20041102

 

Ups..... mhh ich nutze auch gcc-3.4.3, da sollte man die "unstable" von glibc und gcc verwenden... kann ich übrigends auch nur empfehlen, wer schon dabei ist sein System mit nptl neu zu emergen, kann auch gleich zu gcc-3.4.x updaten, da schlägt man gleich 2 Fliegen mit einer Klappe  :Smile: 

----------

## friedegott

 *Mindphaser wrote:*   

> 
> 
> Das dein xmms nur noch ein Prozess anzeigt hat damit nichts zu tun, bei mir ist der Grosteil des Systems schon nptl "konform" und ich sehe immernoch viele Programme die mehrere Prozesse brauchen :-/
> 
> 

 

doch das hat sehr wohl mit nptl zu tun. bei nptl werden mehrere threads unter einem eintrag in /proc zusammgefasst, wohingegen die alten threads jeweils einen eigenen prozess hatten. dennoch kann es aber programme geben die einfach mehrere *prozesse* starten. (zb der apache in standardkonfiguration)

----------

## sven-tek

weiß jemand ob es spürbar was bringt nach dem nptl USE setzten das ganze System neu zu kompilieren? Wie groß sind die Performanz-Vorteile?

----------

## makukasutota

Mein System ist nun neu aufgesetzt und funktioniert auch prächtig. Nun muss ich nur noch (über Nacht oder so) KDE + Xorg kompilieren..

Zu der Performanz: Ich hab mal einen Test gelesen in dem es um 100.000 Threads öffnen + schliessen in unter 2 Sek gab. Insgesamt irgenwie 20 µsek für NPTL pro Thread und >200 µsek p/T bei den alten Linux Threads. Wirklich viel kann ich dazu nicht sagen..

----------

## reptile

nagelt mich nicht drauf fest, aber so, wie ich es verstanden habe, braucht man _nur_ die glibc neu zu übersetzen mit nptl, um alle vorteile nutzen zu können.

----------

## Der P@te

 *reptile wrote:*   

> nagelt mich nicht drauf fest, aber so, wie ich es verstanden habe, braucht man _nur_ die glibc neu zu übersetzen mit nptl, um alle vorteile nutzen zu können.

 

gcc musst du auch schon mit ntpl support mergen. gclib dann mit ntpl so läuft es zumindestens inzwischen bei mir.

----------

## amne

 *Der P@te wrote:*   

> 
> 
> gcc musst du auch schon mit ntpl support mergen.

 

Wie meinen? Ich seh nirgends ein ntpl USE Flag bei gcc.

----------

## Der P@te

 *amne wrote:*   

>  *Der P@te wrote:*   
> 
> gcc musst du auch schon mit ntpl support mergen. 
> 
> Wie meinen? Ich seh nirgends ein ntpl USE Flag bei gcc.

 

Stimmt hab da was verwechselt:

 :Rolling Eyes: 

Ich bezog mich hier auf die Anleitung und da geht es wirklich nur um glibc. 

https://forums.gentoo.org/viewtopic.php?t=206526

----------

## mrsteven

 *reptile wrote:*   

> nagelt mich nicht drauf fest, aber so, wie ich es verstanden habe, braucht man _nur_ die glibc neu zu übersetzen mit nptl, um alle vorteile nutzen zu können.

 

Das dachte ich eben auch, weil die glibc ja in 99% der Fälle dynamisch gelinkt wird.

----------

## zielscheibe

Aus dem Stehgreif fällt mir nur ein Fall ein, bei dem es zu Problemen kam, unter Verwendung des "nptl" Flags im laufendem System. 

Firefoxupgrade bedingte "glib" Update.

----------

