Slashdot Mirror
NVidia Releases Linux Drivers Supporting 4K Stacks
Supermathie writes "NVidia has finally released drivers for their chipsets and the 2.6 kernel that support 4K stacks. That means compatability with Fedora Core 2 kernels, people! View the README, visit their driver page, or download the package."
For me the best way to test these new drivers is to play Enemy Territory
One of the best online FPS games and it's free-as-in-beer.
Keep up the good work NVIDIA.
http://www.kubuntu.org/
It seems that this driver's OpenGL headers are a little buggy, but the solution was given by NVIDIA employee in this thread at nvnews.net forum.
http://lwn.net/Articles/84583/
See you, space cowboy...
I've been testing these drivers under Fedora Core 2 for a while, and they appear to work flawlessly.
Thad
I love Mondays. On a Monday, anything is possible.
For people who are building home theater PCs for things like MythTV, this is a major step forward. The last release that supported overscan (so that a TV image doesn't have black stripes on the sides) was many releases back (version 4363). This release not only supports Linux 2.6 with 4K stacks, but has overscan and interlace support, making it ideal for TV and HDTV display.
It's an essentially obscure change they made in the 2.6 Linux Kernel. The idea was that the smaller stack lets you run more threads and perform better under higher IRQ loads. In reality, since pages are 4KB anyways, and most processors not only swap but also cache memory in 4KB pages, if the stacks don't actually use more than 4KB there's no advantage to artificially limiting them--the other memory doesn't really even need to "exist." It also required rewriting and reworking lots of things, such as these NVidia drivers, that assumed the stack size would be much larger than 4KB.
You can turn off the 4KB stack and go back to the default behavior by recompiling the kernel with the proper option set, but default Linux distros based on 2.6 all use (to the best of my knowledge) 4KB stacks by default.
...with the latest 2.6 kernels, simply turn off 4K stacks. But hey, now it's not necessary. Yay.
4k stacks are a good thing, a first step for Linux to support an insane amount of simultaneous processes on the system.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
this is a cut/paste of this article. Unless you actually wrote it, don't copy with no reference.
I submitted this story last night, and it didn't get posted.
I'll karma whore, since I read the article linked above.
If you allocate memory in 8k stacks, the kernel's got to find 2 pages of memory together. Which I guess gets to be a pain as uptime increases. Since memory pages on most hardware are 4k, it's easy as pie with 4k stacks. Plus, you separate some of the kernel stuff like software interrupt handlers to their own stack (I think that's what it was), hopefully making the system more stable in the process.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
OK... If you're a programmer, you know about stacks; they've been almost THE canonical way to allocate space for the broad family of "Algol-like languages" since the classic reference on implementing Algol 60. If you're not a programmer... you've seen those stacks of plates at cafeterias and restaurants, or of cups at the convenience store? The important property they have is LIFO (last in, first out). Think of each plate as a place where you can write some information. A function is run, it grabs a few plates for the things it needs to remember. When it is finished, it puts the plates back (you can only take an anlalogy so far, of course--if you put your plates back right away at the cafeteria, you'd gross people out). As long as there are enough plates left, it doesn't care who else called it, or how many callers came before it. All it needs to know is to go to the stack and get the number of plates it needs.
When you make a system call, it typically executes on its own stack, separate from the one you get for user state. The question is, how big should that stack be? It constrains how deeply nested you can get into function calls while in system state and how much space they can chew up for local variables. Until recently on Linux it's been 8K bytes (think 8192 plates), but they switched over to 4K, only half as much space (or half as many plates).
Some drivers as written count on having that whole 8K of space to play with, and they have to be rewritten. Since nvidia provides neither an Open Source driver nor sufficient information to allow anyone else to write one, however, it means that we have to wait until they deign to make that change. Fortunately, they've gotten around to it.
so finally nvidia got its act together. i wonder what took them so long?
They are still ahead of the game with Linux compared to ATI. ATI only just got Linux drivers out a few months ago. NVidia has had Linux drivers for at least around 2-3 years now (I didn't really care about it before then), this is just about them getting the 2.6 kernel drivers (and new chipsets). Also, to my understanding, ATI's Linux drivers arn't all that good, and they have yet to support the 2.6 kernel.
So really, if you want a brand name video card that supports Linux, NVidia is the way to go (at least for now).
There is magic in their drivers, and it is explained EVERY SINGLE TIME NVIDIA GETS MENTIONED HERE. It's called a special OpenGL license from SGI and it's also some special in-house code.
Try to remember it this time, it's only the 400 millionth time it's been mentioned.
Are there any video card manufacturers left who release other than binary only drivers?
Matrox releases open-source drivers for some of their product lines (e.g. the Millenium G series -- G400, G450, G550, etc.). The mga driver that comes along with X is the same as Matrox's, for that reason. And 2D performance under the open-sourced Matrox drivers is actually pretty damned good. This all sounds great, doesn't it? Unfortunately, Matrox's Linux support sucks, and the support for Matrox from the DRI project is fairly nonexistent right now. So if you do have any problems with the driver, or want to get 3D/DRI/hardware acceleration issues solved, you're gonna have to learn to hack the drivers/kernel modules yourself. Good luck.
Let's hope ATI follows suit.
It took 2 third party patches and a recompile to get it their driver to install on Fedora Core 2, and it still crashes WineX.
All that we see or seem is but a dream within a dream.
Actually, this is the idea. The interface with the kernel is open source; the closed source code is a binary object that gets linked into the module.
That works great if you can guarantee separation. Otherwise debugging is a nightmare, knowing that there are some black boxes in your system which can manipulate the whole system.
Sorry, user mode doesn't really make much sense here, drivers need full hw access and context switching to a different privilege level would only hurt performance.
Right, that wouldn't work too good - but if everything runs in kernel mode then there is no border control between the driver and the rest of the kernel. The driver has to be trusted to play nice and not to fuck up the kernel data structures, because there's nothing that can stop him doing that. It would be different if the driver ran in user mode, because then the driver would throw segmentation faults and the like if it does something illegal.
The conclusion is that source code should be available for everything that runs in kernel mode.
It also mentions something about interupts that I don't understand.
The problems with interrupts is, that you don't have much control over when they arrive, and when they do arrive, they need stack space. So with interrupts interrupting each other, you can quickly use a lot of stack space. If you were very unlucky, you could probably overflow even a 16KB stack that way.
So you would either have to disable interrupts or make sure there were always enough stack space to take an interrupt. Disabling interrupts is something we don't want to do for more than a few nanoseconds, so something have to be done.
With 4KB stacks this problem become even worse, but there is a solution. Assume we need to be able to handle for example five interrupts at the same time and each of them need 3KB of stack space. With the traditional approach, we would need to always leave 15KB of stack space in every thread. But we are never going to need all of that, because at any time there is only one thread executing on each CPU.
Interrupt stacks means that rather than using the stack of the current thread, we simply switch the stack pointer to a different stack only used for interrupts. We will still use a small amount of stack space in the current thread, but certainly less than 100 bytes, and only for the first interrupt. This means that the thread stack no longer needs to leave free space for some unpredictable amount of data.
The kernel design requires the kernel stack of every thread to have exactly the same size (and a power of two). The current macro on x86 is one piece of code relying on this. But within an interrupt current doesn't make any sense. So it should be possible to make the interrupt stacks larger than the thread stacks. That way we can have a few large interrupt stacks and a lot of small thread stacks. This use less memory than a lot of large thread stacks. The number of thread stacks just have to be one pr CPU or one pr handler depending on your design.
My system currently have 1 CPU, 12 interrupt handlers, and 101 threads. Which means that saving 4KB per thread and then creating a single 16KB interrupt stack would save a lot of memory.
Do you care about the security of your wireless mouse?
Opteron: 4
Alpha: 8
Sparc64: 8
Itanium: 4, 8, 16, 32, or 64 (usually set to 16)
You can always double-up in software. The VAX has
1/2 kB pages (512 bytes), but the Linux port puts
8 of those together to make a 4 kB page.
The 680x0 processor lets the OS choose the page
size to be pretty much anything.