| View previous topic :: View next topic |
| Author |
Message |
pran
n00b
Joined: 19 Nov 2003
Posts: 18
Location: Canada
|
|
| Back to top |
|
 |
Snake007uk
Apprentice
Joined: 12 Jan 2003
Posts: 198
Location: London, UK
|
 Posted: Tue Dec 23, 2003 3:11 am Post subject: |
 |
|
hmm
i could do what the guy mentions, but i owuld like to know what the problem is before jsut doing somehting that works i would like to know what the problem is and why that particular fix, fixes it ?
sorry to be a pain but this is how u learn 
Snake
_________________
Snake
Dual AMD MP 2800+, Asus A7M266-D, 1GB Ram, 18.1GB u160 HD, ATI Radeon 9600 Pro, Creative Audigy ZS, Intel SRCU31A, Linksys NIC, iiyama 18.1 4637bk lcd |
|
| Back to top |
|
|
Praxxus
Apprentice
Joined: 26 Nov 2002
Posts: 193
Location: Indiana, US
|
| Posted: Tue Dec 23, 2003 3:33 am Post subject: Just to chime in . . . |
|
|
I just got done upgrading all my systems to 2.6 + NPTL tonight, after reading some threads (including this one) on this forum. All I can say is, WHAT ARE YOU WAITING FOR?
I'm running the KDE CVS ebuilds, which were already snappier than KDE 3.1.x, but now . . . wow. There's a noticeable difference in the system response. I'm impressed.
All I did was add nptl to my USE flag, re-emerged glibc, and re-emerged nvidia-glx. Everything (KDE apps, mozilla firebird, java, etc.) seems to be fine!
_________________
My glaucoma just got worse! |
|
| Back to top |
|
|
woodwizzle
Apprentice
Joined: 30 Nov 2003
Posts: 225
|
| Posted: Tue Dec 23, 2003 5:49 pm Post subject: |
|
|
| I still don't understand what NPTL is. Can someone explain it to me? |
|
| Back to top |
|
|
Mnemia
Guru
Joined: 17 May 2002
Posts: 476
|
| Posted: Tue Dec 23, 2003 6:03 pm Post subject: |
|
|
| woodwizzle wrote: | | I still don't understand what NPTL is. Can someone explain it to me? |
It's a new mechanism for doing threading under Linux. Threading is a situation where you have several different "lightweight processes" or "threads" working on a piece of code simultaneously. Basically it allows for concurrent execution of multiple parts of the same program which do not depend on each other and the sharing of memory between the different threads. This is something that is vital for the interactive performance of many programs as well as SMP scalability and attending to multiple simultaneous users in a server situation for example. NPTL is a newer mechanism replacing the old Linux Threads interface and it is supposed to be faster and a lot more robust. |
|
| Back to top |
|
|
nepenthe
Guru
Joined: 14 Jul 2002
Posts: 317
Location: Sanford, ME
|
| Posted: Tue Dec 23, 2003 7:27 pm Post subject: |
|
|
emerged only glibc with NPTL support and re-emerged nvidia-glx ....
no problems here =) |
|
| Back to top |
|
|
rsk
Apprentice
Joined: 18 Apr 2002
Posts: 220
Location: Tucson, AZ
|
| Posted: Tue Dec 23, 2003 8:51 pm Post subject: |
|
|
All you "Recompile glibc and glx" people are making us "Must recompile everything to be safe!" people look REAAALLL bad... so just lie and tell us it toasted your system
2.6/NPTL/Full System Reinstall is toatlly on my plate for the new year, maybe mid february. I really want to see those responsiveness updates all at once and get the "wow effect".
_________________
Best,
Riyad |
|
| Back to top |
|
|
MasonMouse
Tux's lil' helper
Joined: 26 Nov 2002
Posts: 146
Location: Texas, USA
|
| Posted: Wed Dec 24, 2003 1:56 am Post subject: |
|
|
If it makes you feel better, I added NPTL to my USE flags and recompiled glibc (no nVidia card here) and lots of things still crash. :)
UPDATE: I recompiled Xfree86 with NPTL and now BZFlag runs fine. Everyone talking about recompiling nVidia GL stuff made me think that it was X's GL drivers causing problems. Still no sound but that'll hopefully be the next thing to work.
UPDATE #2: Finally gave up on ALSA. I removed all traces of it and enabled OSS emulation in the kernel and Everything Just Works(tm).
Last edited by MasonMouse on Thu Jan 08, 2004 12:58 am; edited 2 times in total |
|
| Back to top |
|
|
rsk
Apprentice
Joined: 18 Apr 2002
Posts: 220
Location: Tucson, AZ
|
| Posted: Wed Dec 24, 2003 2:34 am Post subject: |
|
|
Hahha, I appreciate the post, but feel bad your computer isn't working right 
_________________
Best,
Riyad |
|
| Back to top |
|
|
Snake007uk
Apprentice
Joined: 12 Jan 2003
Posts: 198
Location: London, UK
|
| Posted: Wed Dec 24, 2003 3:36 am Post subject: |
|
|
ok, i emerge glic with the use flag set with NPTL, but, although it worked fine i havent had no crashes if i decide to compile the whole system again
e.g
mysql keep stopping from compiling throwing an error about linuxthreads
i did what the precious post mentioned in the link, i added
but it still doesnt work and the file gets overwritten ?? ervrytime during emerge -eb world command ?
can some explain what is going on ?
_________________
Snake
Dual AMD MP 2800+, Asus A7M266-D, 1GB Ram, 18.1GB u160 HD, ATI Radeon 9600 Pro, Creative Audigy ZS, Intel SRCU31A, Linksys NIC, iiyama 18.1 4637bk lcd |
|
| Back to top |
|
|
zhenlin
Veteran
Joined: 09 Nov 2002
Posts: 1361
|
| Posted: Wed Dec 24, 2003 3:40 am Post subject: |
|
|
Load average: ~140
Sound: Excellent.
Basically, a forkbomb started itself (probably due to bad configuration), I didn't come back until about an hour later - the music I was playing was still coming through realtime, no stuttering. The system was a lot less responsive though, Ctrl+Alt+Del took about 6 seconds to be recognised, and shut down took about 30 minutes. |
|
| Back to top |
|
|
Tazmanian
Apprentice
Joined: 01 Jul 2003
Posts: 222
|
| Posted: Wed Dec 24, 2003 6:27 am Post subject: |
|
|
| rsk wrote: | | All you "Recompile glibc and glx" people are making us "Must recompile everything to be safe!" people look REAAALLL bad... |
The rationale for recompiling everything is not because things might break.
Assuming you're just recompiling the same version of glibc as what you currently have, all the interfaces should remain the same. As such, programs that dynamically link against glibc should not break. In fact, they start taking advantage of NPTL immediately.
Programs that statically link against glibc, on the other hand, internally contain copies of the (non-NPTL) glibc code. This means that these programs will definitely not break. On the other hand, they need to be recompiled to take advantage of NPTL.
Presumably, the programs you care about will not link against glibc statically. So you can most likely get away with recompiling only glibc. But those who want every last thing on their system to use NPTL will just have to recompile everything.
[EDIT] One caveat I just thought of is that it may be possible for a package's configure script to check for NPTL and adjust the compile accordingly. I don't know how glibc exports its NPTL capabilities, so I don't know if this is possible..... |
|
| Back to top |
|
|
Tazmanian
Apprentice
Joined: 01 Jul 2003
Posts: 222
|
| Posted: Wed Dec 24, 2003 9:43 am Post subject: |
|
|
For those of you who are recompiling everything (like I am right now  ), check here for a nice alternative to 'emerge -e world'. |
|
| Back to top |
|
|
Mnemia
Guru
Joined: 17 May 2002
Posts: 476
|
| Posted: Wed Dec 24, 2003 9:49 am Post subject: |
|
|
| tazmanian wrote: | | rsk wrote: | | All you "Recompile glibc and glx" people are making us "Must recompile everything to be safe!" people look REAAALLL bad... |
The rationale for recompiling everything is not because things might break.
Assuming you're just recompiling the same version of glibc as what you currently have, all the interfaces should remain the same. As such, programs that dynamically link against glibc should not break. In fact, they start taking advantage of NPTL immediately.
Programs that statically link against glibc, on the other hand, internally contain copies of the (non-NPTL) glibc code. This means that these programs will definitely not break. On the other hand, they need to be recompiled to take advantage of NPTL.
Presumably, the programs you care about will not link against glibc statically. So you can most likely get away with recompiling only glibc. But those who want every last thing on their system to use NPTL will just have to recompile everything.
[EDIT] One caveat I just thought of is that it may be possible for a package's configure script to check for NPTL and adjust the compile accordingly. I don't know how glibc exports its NPTL capabilities, so I don't know if this is possible..... |
I don't think the configure thing is really a possibility, because that would seem to imply that the actual threading API changed. That's not the case, it seems, since as you say and as I can see programs that dynamically link against glibc automatically take advantage of NPTL without a recompile. This would mean that the only thing that has changed is the implementation of the threading API functions in the C library.
While I think you're right that you would need to recompile everything if you wanted to ensure that all programs use NPTL internally, in my opinion this isn't worth it. I think the actual number of programs doing static linking to glibc will be pretty small - who wants to compile something potentially huge like that into their app and hurt resource usage by having redundant copies of it in memory?? I'm guessing that the number of major programs doing such static linking is small and moreover that those that do are the ones most likely to refuse to compile with NPTL at all...
I'm getting a lot of benefit just from the improvement to Java alone, and I didn't recompile anything besides glibc. |
|
| Back to top |
|
|
asimon
l33t
Joined: 27 Jun 2002
Posts: 979
Location: Germany, Old Europe
|
| Posted: Wed Dec 24, 2003 10:42 am Post subject: |
|
|
Some people seem to think that NPTL will make their desktop faster but I think this is wrong.
NTPL brings a performance benefit for systems which spawn a high number of concurrent threads. But the typical desktop is not in this liga. Just do the math yourself and count how many threads KDE, Mozilla, Gnome, emerge or XMMS spawns. Sorry, but NPTL will not boost the desktop expierience. Of course if you use some highly threaded applications things change ... |
|
| Back to top |
|
|
bos_mindwarp
Apprentice
Joined: 19 Oct 2002
Posts: 275
Location: stockholm, sweden
|
| Posted: Wed Dec 24, 2003 11:14 am Post subject: |
|
|
I'm running mm/development sources for quite a while now, and nptl as soon as it arrived. I hear redhat's kernel has backported patches for nptl.
However I am sceptical, does that mean that they ported everything related to threading and scheduling, or just some interfaces?
Also for programs that link to threads dynamically, you don't need to recompile, but you have to do it for statically linked ones. Which programs go into which category, I have no idea. I did run my system with only recompiling glibc and kernel and it worked.
Note that if you plan installing oracle, I think it doesnt work with nptl. |
|
| Back to top |
|
|
Corw|n of Amber
Apprentice
Joined: 08 Aug 2003
Posts: 221
Location: Socialist Sovietic Republic of Belgium
|
| Posted: Wed Dec 24, 2003 11:43 am Post subject: |
|
|
Recompile everything??? Why? There *is* a program/script/whatever that checks your system to find the libs/binaries/stuff that need to be re-emerged to keep compatibility. Works great. Can't remember the name
_________________
Whoever is enough of a fanatic to KILL people should be shot on sight. |
|
| Back to top |
|
|
asimon
l33t
Joined: 27 Jun 2002
Posts: 979
Location: Germany, Old Europe
|
| Posted: Wed Dec 24, 2003 11:55 am Post subject: |
|
|
| bos_mindwarp wrote: | I hear redhat's kernel has backported patches for nptl.
However I am sceptical, does that mean that they ported everything related to threading and scheduling, or just some interfaces?
|
Author of NPTL is Ulrich Drepper a Red Hat employee, thus you can bet that Red Hat/Fedora actually has a very good and working NTPL implementation in their kernels.
Red Hat's kernel has full NPTL, nothing half-baked. They also backported most of the vm/scheduler stuff, which is the reason why Fedora/Red Hat people don't see such a big performance boost after upgrading to kernel 2.6 as others do. Much of the performance enhencing stuff which is new in 2.6 was already in their stable 2.4.x kernels. |
|
| Back to top |
|
|
Jazz
Guru
Joined: 16 Nov 2003
Posts: 543
Location: Melbourne, Australia
|
| Posted: Wed Dec 24, 2003 12:16 pm Post subject: |
|
|
Lol, RH has employed many best people in their fields and yet RH sucks  what a pity ! |
|
| Back to top |
|
|
asimon
l33t
Joined: 27 Jun 2002
Posts: 979
Location: Germany, Old Europe
|
| Posted: Wed Dec 24, 2003 12:33 pm Post subject: |
|
|
| jassi wrote: | | Lol, RH has employed many best people in their fields and yet RH sucks what a pity ! |
I don't think they suck. They brought us much inovation like freedesktop.org, NPTL, work on gcc, glibc, binutils, kernel, xfree, fds etc. and push Linux into the corporate world. What has Gentoo done to improve the Linux platform? Not much. |
|
| Back to top |
|
|
vificunero
Apprentice
Joined: 25 Jul 2003
Posts: 244
Location: Milan Italy EU
|
| Posted: Wed Dec 24, 2003 1:43 pm Post subject: Re: Kernel 2.6 (NTPL) Desktop Impressions? |
|
|
| Nightwish wrote: | | rsk wrote: | Hey, I'm hoping the more brave group out there can help me with this one. I just finished getting my nice stable machine installed with everything up to date and optimized (Well atleast as much as it can be) with Vanilla Kernel 2.4.23 and KDE 3.1.4
One thing I noticed that I hadn't noticed this much before was just how sluggish the desktop (especially Eclipse-GTK) feel. There is a tone of flashing, repainting, etc. This is on a P4-2.8Ghz w/ GF MX 420 card, so its not a sluggish machine, but the video card is on par with a GF2) |
I hate to say that, but it' because GTK, plain and simple, sucks, when compared with other toolkits like wxWin or QT.
I really never understand, why GTK got so much interest by developers... well, maybe, because back in the days when GTK became popular, there weren't any good alternatives besides Motif, which, of course, sucks even more (and was proprietary at that time).
GTK2 is even worse when it comes to screen redraw performance. On a slower machine (my "playground" is an old P3-600 with only 256 MB RAM), themed GTK2 apps are horrible. You can almost watch them drawing their menu items or dialog box controls. QT/KDE on the other side feels "snappy", even with more complex themes like thinkeramik and font antialiasing.
In general, I try to avoid GTK apps if possible, that is, of course, not always possible.
Aside from this, GTKs API is a nightmare
|
I'm sorry but with a pentium 300 mhz and 128 mb ram I have no problems with gtk2 applications. Yes there are some heavy themes but generally they don't create problems. I use gorilla theme and it's perfect on this old machine.
My experience with kernel 2.6 is very positive till now. I use it since the test9 release and everything works fine and has a faster compilation too. |
|
| Back to top |
|
|
nepenthe
Guru
Joined: 14 Jul 2002
Posts: 317
Location: Sanford, ME
|
| Posted: Wed Dec 24, 2003 6:27 pm Post subject: |
|
|
| asimon wrote: | | jassi wrote: | | Lol, RH has employed many best people in their fields and yet RH sucks what a pity ! |
I don't think they suck. They brought us much inovation like freedesktop.org, NPTL, work on gcc, glibc, binutils, kernel, xfree, fds etc. and push Linux into the corporate world. What has Gentoo done to improve the Linux platform? Not much. |
I would imagine having such a large user base, testing and finding bugs for such a broad range of developemtal-status programs which is only continually growing... would be aiding in the improvement of the Linux platform greatly... perhaps just in smaller ways.
Not to digress... |
|
| Back to top |
|
|
zhenlin
Veteran
Joined: 09 Nov 2002
Posts: 1361
|
| Posted: Thu Dec 25, 2003 2:38 am Post subject: Re: Kernel 2.6 (NTPL) Desktop Impressions? |
|
|
| Quote: |
I hate to say that, but it' because GTK, plain and simple, sucks, when compared with other toolkits like wxWin or QT. |
How silly can you get... wxWindows for X11 is implemented in GTK+ .
I currently have a P4 2.8GHz, GF4MX, 1GB RAM... But even under my previous system, P4 1.5GHz, GF2MX, 256MB RAM -- GTK+ worked at a reasonable speed.
But you can never know slow until you've seen fast.... So maybe I don't know.
| Quote: | | I really never understand, why GTK got so much interest by developers... well, maybe, because back in the days when GTK became popular, there weren't any good alternatives besides Motif, which, of course, sucks even more (and was proprietary at that time). |
GTK+ is...
* LGPL
* C
Those two alone attract lots of developers. There are still a lot more C programmers out there than C++ programmers. GTK+ is Object-Oriented though... It just doesn't use a natively OO language.
| Quote: | | In general, I try to avoid GTK apps if possible, that is, of course, not always possible. |
Actually, it is near impossible... GIMP is done in GTK+, this has no Qt alternative, Mozilla is GTK+, Konqueror isn't as featureful (no XML parsing, no XSLT, just to name some), Mono will undoubtedly use GTK+ for its Windows Forms implementation...
Aside from that, GTK+ has a few things Qt doesn't, as I've begun to notice... GTK+ has native, runtime-switchable IMEs. Meaning, no need to relaunch an app using a different LC_CTYPE/LANG/LANGUAGE to use a different IME. GTK+, in conjunction with Pango, has automatic font-substitution, Qt, does not appear to.
| Quote: | | Aside from this, GTKs API is a nightmare |
Only if you use C++... |
|
| Back to top |
|
|
i_hate_your_os
Tux's lil' helper
Joined: 29 Aug 2002
Posts: 128
Location: Manhattan Beach, CA
|
| Posted: Thu Dec 25, 2003 4:07 am Post subject: NPTL |
|
|
One of the coolest things about NPTL: in sun-jdk-1.4.2, java threads are no longer linux processes. This can make a big difference.
As for the thing about whether to recompile everything: it can't hurt, right? (famous last words, I know...) Seriously, it's good for the health of your gentoo to recompile stuff.
OTOH, you are going to have apps that use linuxthreads -- it's not like everything is magically ported to nptl, many apps will take time or may never be ported. So don't worry about it too much... if you recompile your glibc, the slow progression of gentoo rsync updates will eventually "port" your system to nptl.
As for the subjective stuff.... if you have a decent cpu like me and want a really slick interactive desktop with audio that doesn't skip, like you thought you paid for, get love-sources and set your nptl use flag... once you try it, you will never want to go back (which is a good thing, since you can't (j/k, you could, but it would take some effort)).
_________________
-IHYOS
"All laws which are repugnant to the constitution are null and void."
-Marbury vs. Madison, 5 US (2 Cranch) 137, 174, 176, (1803) |
|
| Back to top |
|
|
zhenlin
Veteran
Joined: 09 Nov 2002
Posts: 1361
|
| Posted: Thu Dec 25, 2003 3:35 pm Post subject: Re: NPTL |
|
|
| i_hate_your_os wrote: | | OTOH, you are going to have apps that use linuxthreads -- it's not like everything is magically ported to nptl, many apps will take time or may never be ported. So don't worry about it too much... if you recompile your glibc, the slow progression of gentoo rsync updates will eventually "port" your system to nptl. |
Nothing should be ported (rewritten), given that LinuxThreads and NPTL are just implementations of pthread. But... there is some code designed to work around flaws in LinuxThreads ... These need to be removed before they work well with NPTL.
Everything is automatically ported, in the sense that NPTL must be binary compatible with LinuxThreads -- they both come in the library libpthread.so, with a major version number of 0 - which denotes binary compatibility. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
