LinuxWorld: Stronger I/O & VM Coming Soon to Linux

Mark Brunelli, News Editor writes "Tim Witham, CTO of Open Source Development Labs and a featured speaker at LinuxWorld, says the next Linux kernel will feature improved input/output and virtualization capabilities. Said Witham: 'Enabling virtualization is a big win [for Linux 2.6] as it allows IT shops to start their development cycles for a technology they will be looking at deploying within the next year or so. There has been lots of good work done with regard to system scalability, memory management, disk I/O, process and thread scalability. Also, work done for availability, like a greatly improved multi-path I/O [were victories].'"

Comments

Content-free

[interiot]

Since the linked article seems to no more information that what the summary says, here's another link that discusses virtualization+kernel a little more. It looks like it's the Xen work that's going into the kernel (the project that IBM and AMD and others have been putting money and developers into to get working).

Terrible title

[SlashEdsDoYourJobs]

'VM', in the context of the Linux kernel, refers to its virtual memory manager, not virtual machines. It's incredibly misleading to read about 'stronger VM' like this.

Wasn't usermode Linux integrated into the 2.6 kernel anyway? What improvements in virtualisation is TFA referring to? It seemed remarkably short on details.

Re:Terrible title

[ComputerSlicer23]

VM refers to both, just depending on the context. While I agree with you I generally think of VM as Virtual Memory, not as Virtual Machine, it's just one of those things. For the first six months they talked about UML and getting it integrated into the kernel, I thought they were talking about "Unified Modelling Language". Just get over the title. Your initial assumptions and intuition misled you. Shocking.

User Mode Linux is in 2.6, however, I believe they are referring to "Xen" which is a separate "arch" (like PPC, x86, SPARC). It is essentially an "arch" all it's own so that it can implement the low level details it needs to provide to the hosted OS's, but it has to run on top of a standard Linux kernel. It's an interesting concept.

Kirby

Re:Terrible title

[jd]

I believe they're referring to Xen, which can virtualize (in theory) any OS - not just Linux - and is (reputedly) considerably faster than UML.

Re:Terrible title

[stevey]

No Xen cannot virtualize/host any OS.

Instead the OS must be modified to support it. If you look at the Xen homepage you'll see more details.

Whilst this doesn't diminish the usefulness of the project it does mean you cannot host an XP installation - like you can with Qemu , or the commerical software VMWare.

I have used Qemu extensively in the past to host installations of Windows upon my Debian machine - whilst it is not as fast as Xen promises to be it is the best around at the moment (short of spending cash!)

What's with Linux and Disk blocking anyway?

[bill_mcgonigle]

What's the deal with disk I/O killing the responsiveness of the system anyway? When you have to move monstrous amounts of data, a Linux system can get practically unusable, no matter which user is initiating the load.

I used to think this would go away with faster machines, or the interrupts would be freed by using SCSI HBA's, but the symptoms still persist today, even on a modern 'fast' machine.

I never experienced anything like it on, say, Sun hardware, in the pre-Linux days.

Re:What's with Linux and Disk blocking anyway?

[gid]

I agree it's annoying, even using a pre-emptive kernel doesn't seem to help much anymore, although I swear it used to.

Re:What's with Linux and Disk blocking anyway?

[oliverthered]

And I've just spent the last 6 months trying to find out what's hanging on to that IRQ and blocking everything else..

DMA should stop this from happening (I wonder if it happens outside X86)

Re:What's with Linux and Disk blocking anyway?

[Anonymous Coward]

The simple answer is Linux uses write-back caching, and will let a process write data faster than it can actually be sent to the disk, thus filling up all the available memory pages and blocking other I/O.

Re:What's with Linux and Disk blocking anyway?

[wild_berry]

Shouldn't the kernel tell the task to slow up when you're getting toward 2/3 (or 50%, 75%, 80% etc.) of the available memory pages? Would boot-up tests that store data-rate metrics for the available storage allow the system to slow down tasks likely to fill the memory pages before the disks can catch up which would allow the system to retain 'teh snappy'?

Some thoughts

[jd]

Once virtualization is introduced into microprocessors, you will be able to run a real copy of Windows in parallel to Linux, using Xen.

Improved I/O means home networks should run closer to the capabilities of the wire, plus multimedia on the computer is less likely to stall when playing. It may also make Linux more attractive to games writers, as a lot of games these days are heavy on multimedia.

Re:May be what the Linux community needs

[cant_get_a_good_nick]

Not sure if that was a real post or meant to be humor, but mucking with the VM is not the way to be more stable. There were major stability issues in the early 2.4 kernels due to the new VM that was swapped in. My company is still dealing with bugs in what can be seen as a VM issue - the 4Gb user/4Gb kernel split in RedHat advanced server, and this is in the new U5 update.

Re:May be what the Linux community needs

[cant_get_a_good_nick]

My mistake, article was (though unclear) talking more about Virtual Machines than Virtual Memory, I guess I'm too frustrated at having the occasional kernel panic...

Re:Which next kernel?

[Lemming Mark]

Xen support won't be in 2.6.13 but could be in 2.6.14. Basically the hold up is in restructuring to fit with emerging kernel policies on x86-like architectures (i.e. fit them into the i386 directory, instead of forking a separate arch tree as x86_64 did). Once this restructuring is done, the Xen patches should get merged.

Also according to their info...

[jd]

...once CPUs are capable of supporting virtualization directly (the next generation of Intel and AMD should do this), host OS modifications will not be required.

So, whilst you are correct it cannot virtualize any OS on current processors, that is not quite the same as saying it can't virtualize any OS in the future, which is what I was referring to. Apologies on my part if I wasn't clear on that - I'm not always as clear as I could be.