I built a custom kernel without debug, as well as others, and nvidia driver compiles without problems.

In addition, I may be subjective, but the new kernel, without debug, it seems faster. At least in my case, on the full-HD resolution (1920x1080) with nvidia 331.67, the difference in behavior of KDE feels definitively snappy.

Hello,

From Linux Device Drivers, 3rd Edition (4.1. Debugging Support in the Kernel):


--
SeB

In other hand, turning it OFF, make all other debugging options unavailable. Like a kill-switch.


Of course that the kernel debugging introduce a performance penalty. Depending on the particular hardware and the system load, that performance penalty can be semnificative or unobservable.

For further comments, will be nice if you show us your hardware details. Processor, memory, motherboard, videocard, etc...

I have a Phenom 9550, quad-core at 2200MHz, on a MCP78S motherboard (Asus with chipset nVidia GeForce 8200), 4GB DDR2 800Mhz, 4 bars in dual channel (ganged), the video card is that on-board. Monitor Asus VH242H (native 1920x1080), connected using DVI-D cable.

A nice computer, that should "snappy" run the KDE with all whistles and bells...

But, lets do a little review. You have a high resolution monitor (if I remember right, is about 24 inch that model?), driven by an on-board video. GeForce 8200 isn't a bad video, even if an entry level like GeForce 8400GS is superior.

Still, you have a relative huge processing power. That four cores can do things and can really help the video part, BUT I believe that I discovered a little problem in your configuration. Thing that can explain that you are around the limits of video processing. You remember? Your system was sensitive to debug induced performance penalty.

So, the keyword is "ganged". You believe that you do the right thing, going dual channel. In this way, your memory virtually work at 1600MHz, BUT another things go wrong.

A little theory. Phenom have two memory controllers integrated. Them can form two memory channels in "ganged" mode, aka "dual channel", or four memory channels in the mode "unganged". You use, like we see, the ganged way and you have two memory channels.

From the memory controllers POV, there we have the following processing units: CPU cores (four) and the GPU (really, the number five), all considered equal. Because we have only two memory channels, not all the processing units can have simultaneous access to memory, only two, the other three will wait. The percentual success of the memory access rate is:

2 / 5 = 0.4 (40%)

In this way, if you have a little system loading, your GPU can copiously wait for access to memory and your processor cores are underused.

BUT, If you change the memory configuration to "unganged", because Phenom is a strange animal and all the four memory channels can be accessed simultaneous, we have a percentual success of the memory access rate of:

4 / 5 = 0.8 (80%)

In other words, in any moment, four from five processing units will have access to memory. Your processing power will be better used, your GPU will have a better memory access.

Yep, that BIOS configuration change, ganged -> unganged, is a simple way for further "snappification"...

3 members found this post helpful.

Series 9 card:
Had to go back to 3.10.30
331.67 installs with the errors that cwizardone mentioned but works.

Sometimes it's useful to do some real world testing:

http://ixbtlabs.com/articles3/cpu/am...ganged-p1.html

Conclusion: There isn't such a clear picture (that's why there is a setting) and in practice the difference between ganged vs. unganged is almost irrelevant. You will never gain the time back you waste in going to the BIOS setup and changing the setting instead of doing something productive.

If your GPU supports it, you may be better of just sticking with nouveau and building a newer kernel, xf86-video-nouveau and drm/mesa stack if required. I rarely build newer mesa because it's too much time/hassle, but a newer kernel, xorg driver and possibly drm usually improves things and you will almost always get better xserver performance than the blob gives - which is really just focused on gamers.

Thank you! I confirm this further "snappification".

More precise, my "video card" behave much better and the desktop is more fluid on heavy system loading (i.e. compiling the kernel with make -j5), probably because the more "democratic" access to memory.

And I was at a step to "divorce" from my on-board video, looking to buy a discrete one, because I ever considered it sluggish. Now I have no complaint about his (desktop) performances.

For me, the real world testing isn't looking to dubious Windows benchmarks on Internet. It's the real testing. And I'm satisfied of what I found. Thank you for your wasted time looking for questionable Windows benchmarks while is very clear that we talk about Linux and multitasking use of a quad-core and a on-board video, and you can be sure that I understand well that your time spent doing this research will never be back.

With the latest update (kernel update to 3.14.4, with CONFIG_DEBUG_KERNEL set to off), NVIDIA driver installs and works fine. So I'm marking this issue as solved.

1 members found this post helpful.