Joseph Pranevich has written a lengthy article discussing the changes to the Linux kernel for the 2.6 release. It covers topics such as scalability, responsiveness, the re-written IO subsystem, improvements to support for filesystems such as NTFS and XFS in addition to support for new technologies such as Bluetooth and much more.
The Wonderful World of Linux 2.6
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I am more interested in server performance – I understand the need to improve desktop responsiveness, but what I want to know is will this increase server throughput performance
YES!!! More fine-grained locking, asynchronous tcp/ip stack, asynchronous i/o, new block layer rewrite, new i/o scheduler (Anticipatory Scheduler rocks!), new process scheduler, hugely improved threading, hugely improved VM, and much more. Yes, servers will also notice a good pick in the pants concerning performance. Perhaps more so then desktop users.
“The first is that the new edition of the kernel now supports full software-suspend-to-disk functionality for the Linux user on the go.”
“The new version also supports the ability of modern mobile processors to change speed (and power requirements) based on whether you are plugged in or not.”
Ok so now we have hibernate. Cool.
So no wonder every time I boot into redhat9 on my HP Pavilion ze1250 the fan just runs at 100% full time. In windowsXP the fan dosen’t spin till you hit about 70% CPU usage for more then 3 seconds.
I also have an issue with being able to monitor my battery usage in Linux. It would be nice if more support is included – along wit auto hibernate if your battery gets too low. I think the battery applet for gnome will do this.
I am also excited about the new sound system. Does this mean we can DUMP all sound servers like esound, kde arts, ECT?
I’ve noticed several different Linux apps tend to try to use a different method of playing sound and I think that is plain stupid. The fact that in xmms you have to pick an output plug-in and choose between, oss, esound, arts, alsa is stupid. A newbie can have a hard time just getting an mp3 to play. Not to mention other apps that I wish could play sound without some kind of tweaking; like flash in mozilla.
it is nice idea but for home users how big is the improvements
Huge, even older machines will see a rather large improvement across the board. *Everything* for me is faster, even apps launch more quickly.
Hi,
I think Linux shared library system needs to be reworked to launch programs quicker. I just compared OpenOffice running on MacOS on a Power Mac 7200 120 mhz with Linux on my Athlon XP (2100+). The Mac version launched in 1/3rd the time. And this is on a _much_ older system!
Huh?
OOo loads slow as hell on my 1Ghz G4, comparable to my AMD K6-3 450Mhz machine. Can you even run OOo on 120mhz?
Yes, I imagine with enough RAM (192 min) it would run fine. Especially with NPTL (threading overhead being much lower) it should be quite usable. It is on my 266 mhz laptop, no prob.
so that suspend to disk thing, is that like in windows xp where i can completely powerdown my laptop and when i turn it back on it’ll just pick up my gnome, web browser, whatever, sessions?
does there need to be some gui for this? ie does gnome have to support it?
sounds cool! i never thought we’d get such a feature…
* If you follow the software suspend (swsusp) mailing list, there are still some issues to be hammered out, but version 1.0 was released today. Also, ACPI, the power management, is still far from mature — ACPI assembly interpreter works fine, but not too many laptops have specialized drivers written for them. I had to do some hacking to ACPI to work on my Compaq 2800T (aka Evo800). BTW, the new swsusp should also do suspend-to-RAM; regular “sleep” is still a ways off until the device drivers can be made to behave better on reinitialization.
* ALSA already supports hardware mixing, and should support software mixing by using “shared memory” (“dmix” device) but I haven’t gotten it to work. There are other reasons to use a userspace daemon like JACK (asynchronicity, etc.), which can dovetail with ALSA quite nicely.
> so that suspend to disk thing, is that like in windows xp where i can completely powerdown my laptop and when i turn it back on it’ll just pick up my gnome, web browser, whatever, sessions?
does there need to be some gui for this? ie does gnome have to support it?
Yes, exactly — I use it all the time on my system (GNOME2, etc.). I have to run a script that stops/restarts some PCI and USB services because the related drivers misbehave on resume; the central command is
# echo -n 4 > /proc/acpi/sleep
“I’ve noticed several different Linux apps tend to try to use a different method of playing sound and I think that is plain stupid. The fact that in xmms you have to pick an output plug-in and choose between, oss, esound, arts, alsa is stupid. A newbie can have a hard time just getting an mp3 to play. Not to mention other apps that I wish could play sound without some kind of tweaking; like flash in mozilla. ”
Now come on this is not as bad as you make out to be. In Mandrake, RedHat and Suse this gets setup during the install process and always work if the your distro picks up your sound card. I understand the need to start dumping sound servers like esound or arts in favor of ALSA or OSS. Actually I would like it if ALSA and OSS were the only ones left. The reason being for keeping OSS around is that OSS comes in handy for rare or new sounds cards with no driver support in ALSA. You got to have a back-up and the guys at 4Front Tech are always developing new drivers for cards that ALSA does not support yet. Yet to get back to the orginal topic. I never found it to be the case that after an succesful install of a distro ( that detected my sound card ) that I needed to select a sound server in XMMS. That has only happened when I couldn’t get my card to work under ALSA and thus needed OSS drivers from the guys at 4Front Tech and usually XMMS after the install picks up that I am using OSS drivers in most cases.
“Unified Device Model
Often over-looked as a separate component of an operating system, a device model is nearly essential for an OS that is designed to run on a wide variety of hardware. In a nutshell, the device model is the infrastructure within the kernel for detecting and determining the resource usage of all of the optional components of the system. All operating systems (and versions of Linux) intrinsically have some device concept. Older versions of Linux (2.2 and previous), had only a bare-bones approach to handling devices. There were drivers for different types of hardware busses and the various device drivers knew how to probe the device busses that they supported to find their hardware. This system was very spread-out and the various busses had various and incompatible APIs for handling the various operations. Linux 2.4 was the first stage in a “unified” device model by joining PCI, PC Card, and ISA Plug-and-Play into a single device structure with a common interface. Linux 2.6 has vastly expanded on those efforts to produce a completely new view of how the Linux kernel sees the hardware it is running on that is universal across the system.”
I am glad they are going this route and I can’t wait to see the finished work.
I understand the need to start dumping sound servers like esound or arts in favor of ALSA or OSS. Actually I would like it if ALSA and OSS were the only ones left.
Do you actually know what arts and esound do? It seems not.
The problem with Alsa and OSS, is that only one application can play sound at the same time. Thus with OSS, system event sounds are disabled when playing an MP3, for example. This has exactly been the problem of Windows’ sound system too.
Therefore, Arts and Esound exist. All the sounds of the applications that use one of them, are mixed and then sent to Alsa or OSS, thus making that XMMS, Mozilla and KDE can output sound at the same time, in parallel, mixed by Arts/Esound.
For this, I do not think they should be dumped, no, instead they should be even used more extensively! The server should be started at system startup, and all applications should abandon support for OSS/Alsa and implement Arts/esound support instead (preferably both, and autodetect wich one to use)
And then something different: great to see NTFS write support being developed, but is UFS-write-support also being developed? It would be very handy if I were able to mount my BSD partitions read-write, so I can copy data between BSD and Linux.
“The problem with Alsa and OSS, is that only one application can play sound at the same time.”
Nope. This is a popular misconception. Check out the “Alsa vs OSS” article at http://www.linuxhardware.org/features/01/03/06/179255.shtml. For instance, it says, regarding the advantages of ALSA:
—
Hardware Mixing is a particularly helpful feature as it eliminates the need for a software mixer such as ESD. You will need one or the other to allow multiple sound sources to play at once. Most of these capabilities are now available in some OSS drivers, but aren’t as elegantly implemented.
—
While many cards support hardware mixing now, there is still a good argument for using a sound server, but only if it’s a really good one.
JACK is the best I have come across. It allows multiple apps not only to communicate with the sound card, but also to talk to eachother.
That’s like having Steinberg’s Rewire enabled in every audio application you run, along with low latency operation, transport master/slave, 32bit float data paths, and minimal cpu overhead from the server.
It’s only possible to do this at low latencies with the pre-empt (and preferably low latency patches as well, but it seems to run fine on my computer with low latency off) that 2.6 provides.
It’s mostly audio apps that are using it at the moment, but I hope to see it more widespread as it’s a truly professional solution, with an easy API.
Additional reason to use sound servers is network transparency. You can connect to a system with remote X-terminal with running esound or artsd and still be able to play sound.
Yeah, I’ve heard about this but I haven’t been able to find out how to do it. Any tips, or link to how-tos (using aRTS, specifically)?
I’ll download, test, and than pay for 2.6, and after that I don’t think I’ll ever need another upgrade.
No matter how good the new kernel is, I don’t think the new scheduler is going to make up for xfree’s architectural problems. I was also hoping that the ELF dynamic linker would run in kernel space so apps like OO.o would load faster…
How often have I heard about the X-problems? i believe it was in 1992, in the Unix-Haters Handbook. I’m getting bored with it.
And to see how much difference the kernel can make to X, install Debian 3.0 and SuSE 8.2, both with Konqueror, and scroll some anti-aliased text. You’ll be suprised how much smoother this goes in SuSE.
No, I was a little child in 1992, but have recently downloaded that book.
Bah, I just tweaked X with some CFLAG optimizations and now it’s more responsive than some window managers in Windows.
Regards,
Mystilleef
how did u do the optimizations on CFLAG?
Get a -ck kernel for starters. That provides massive improvement.
esd -tcp -public -promiscuous does it for esd. Couldn’t figure how to do it with artsd.