Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Virtualized Linux Faster Than Native?

ScuttleMonkey posted more than 8 years ago | from the too-specialized-to-count dept.

153

^switch writes "Aussies at NICTA have developed a para-virtualized Linux called Wombat that they claim outperforms native Linux. From the article: 'The L4 Microkernel works with its own open source operating system Iguana, which is specifically designed as a base for use in embedded systems.'" Specific performance results are also available from the NICTA website.

cancel ×

153 comments

Sorry! There are no comments related to the filter you selected.

Curious warning on the website (5, Funny)

LiquidCoooled (634315) | more than 8 years ago | (#15434194)

Warning

Running a virtual Iguana OS from within a virtualised Linux environment is dangerous.
ETROS and NICTA will not be held responsible for any resulting time paradoxes.


hmmmm

Re:Curious warning on the website (5, Funny)

Rorian (88503) | more than 8 years ago | (#15434213)

Well thats the answer to the better-than-native performance then. It simply creates a hole in the space-time continuum, off-loads all processing work to the infinite monkies with infinite abacuses, and reports 0.0 cpu load to the benchmark program.

Obvious really.

Re:Curious warning on the website (0)

Anonymous Coward | more than 8 years ago | (#15434503)

So it's essentially a Quantum computer?

Re:Curious warning on the website (0)

Anonymous Coward | more than 8 years ago | (#15435105)

Well, they say it was.

Re:Curious warning on the website (2, Funny)

AndroidCat (229562) | more than 8 years ago | (#15434223)

"The other day I put instant coffee in my microwave oven ... I almost went back in time." -- Steven Wright

Important safety tip, thanks Egon.

KLAATU... VERATA... (4, Funny)

dsginter (104154) | more than 8 years ago | (#15434325)

NICTA... necktie...

Definitely an n-word.

Re:Curious warning on the website (1)

agent dero (680753) | more than 8 years ago | (#15434375)

NICTA is pretty good about a sense of humour, in one of their Darbat [nicta.com.au] SConstruct files (scons is a miserable build system, like GNU/Make but with much less cowbell) they have the following at the top of the file:

SetOption('implicit_cache', 0)
#blah
"""
AHRRRRRRRR!
"""
Import("*")

Rumour has it, it's to make scons work correctly, oops.

like no way (-1, Troll)

Lolzownz (888492) | more than 8 years ago | (#15434195)

like no way!

Ignite the flames of the microkernel debate again? (2, Interesting)

Enderandrew (866215) | more than 8 years ago | (#15434204)

I can Linus already gearing up to defend his position that microkernels are crap.

However, I thought the purpose of a microkernel was stability, not performance.

Re:Ignite the flames of the microkernel debate (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15434254)

I can Linus already gearing up to defend his position that microkernels are crap.

Muaaaaahahahahahahaha!!

Signed,
AST

defend his position that microkernels are crap? (1)

smitty_one_each (243267) | more than 8 years ago | (#15434256)

What's to defend? Whenever a free microkernel design comes remotely close to the mindshare of Linux, there may be a basis for discussion.

Re:defend his position that microkernels are crap? (3, Informative)

AKAImBatman (238306) | more than 8 years ago | (#15434315)

Whenever a free microkernel design comes remotely close to the mindshare of Linux, there may be a basis for discussion.

QNX [wikipedia.org]

'Nuff said.

Re:defend his position that microkernels are crap? (1)

Wdomburg (141264) | more than 8 years ago | (#15434374)

'Nuff said.

Only if you don't read every word in the senteneces you're responding to. And ignore that most people have never heard of QNX.

Re:defend his position that microkernels are crap? (2, Informative)

AKAImBatman (238306) | more than 8 years ago | (#15434981)

Free [qnx.com] (as in soda pop)

'Nuff said.

Re:defend his position that microkernels are crap? (0)

Anonymous Coward | more than 8 years ago | (#15435053)

Retard.

Re:defend his position that microkernels are crap? (1)

Poltras (680608) | more than 8 years ago | (#15435140)

Insensitive Clod.

Re:defend his position that microkernels are crap? (1)

alexhs (877055) | more than 8 years ago | (#15434379)

> > Whenever a free microkernel design comes remotely close to the mindshare of Linux, there may be a basis for discussion.

> QNX

You missed one word... In the free software world, I think L4 is the way to go...

Re:defend his position that microkernels are crap? (1)

bhirsch (785803) | more than 8 years ago | (#15434396)

Traffic lights != tons of web servers...

Re:defend his position that microkernels are crap? (1)

LurkerXXX (667952) | more than 8 years ago | (#15434591)

If QNX were opensource, you would see it on a ton of webservers real quick. It's brilliant code. They had a full operating system, GUI, modem drivers, and web browser, that all fit nicely on a floppy. You can't do that without very well written code.

Re:defend his position that microkernels are crap? (2, Insightful)

RedDirt (3122) | more than 8 years ago | (#15434841)

> They had a full operating system, GUI, modem drivers, and web browser, that all fit nicely on a floppy. You can't do that without very well written code.

Not quite sure that follows. After all, you can do that* with DOS and I don't believe anyone would claim that it's well written code.

* Well, more or less. You can fit that wacky Caldera browser, Arachne [tiscali.co.uk] , (beware the 'orrible MIDI music) and some rudimentary network tools (SSH, VNC and ping) on a floppy. Arguably that's not a "full operating system", but I do think my point size != quality still stands.

Re:defend his position that microkernels are crap? (1)

Nevyn (5505) | more than 8 years ago | (#15435305)

You should look at dietlibc and fnord, they are tiny but I wouldn't use the words well written. I'd like to give QNX more benifit of the doubt than assuming it's just as bad, but small is not the same as beautiful.

Re:defend his position that microkernels are crap? (1)

Deliveranc3 (629997) | more than 8 years ago | (#15434807)

NOT FREE.
'Nuff said.

Re:defend his position that microkernels are crap? (2, Interesting)

diegocgteleline.es (653730) | more than 8 years ago | (#15434340)

He doesn't thinks microkernels are "crap".

He just wants to build a stable, reliable and fast operative system, like the microkernel guys and like veryone else. The difference is that microkernel guys think that the One Way to achieve that is to compartmentalize everything. Linus however seems to think that the microkernel model makes programming much harder (due to multiple separate address spaces, etc) and that a monolithic kernel makes programming so much easier, than in return you get a stabler, faster kernel.

Re:defend his position that microkernels are crap? (1)

DrSkwid (118965) | more than 8 years ago | (#15434529)

300+ syscalls, how hard can it be?

Re:defend his position that microkernels are crap? (2, Insightful)

diegocgteleline.es (653730) | more than 8 years ago | (#15434686)

Implement a VFS, the full networking stack as microkernel subsystems and came back to tell me how many different IPC calls you have in your hands

Re:defend his position that microkernels are crap? (0)

Anonymous Coward | more than 8 years ago | (#15434405)

Whenever Linux adoption coms remotely close to that of Windows, there may be a basis for discussion.

Re:defend his position that microkernels are crap? (2, Insightful)

lp-habu (734825) | more than 8 years ago | (#15434453)

What's to defend? Whenever a free microkernel design comes remotely close to the mindshare of Linux, there may be a basis for discussion.

I hate to point this out, but if mindshare is the criterion then Windows wins. Considering that the average person is almost always wrong, I tend to think that mindshare is a warning flag, not a recommendation.

Re:defend his position that microkernels are crap? (1)

smitty_one_each (243267) | more than 8 years ago | (#15434649)

Point taken, but, nevertheless, consider that you've fallen into the classic boo-boo of comparing a full operating system with a kernel.

Re:defend his position that microkernels are crap? (1)

lp-habu (734825) | more than 8 years ago | (#15434699)

Point taken, but, nevertheless, consider that you've fallen into the classic boo-boo of comparing a full operating system with a kernel.

Actually, I didn't take a position at all on the original question so I wasn't comparing anything with anything. I'm agnostic on the issue.

Re:defend his position that microkernels are crap? (1)

smitty_one_each (243267) | more than 8 years ago | (#15435153)

Fair enough, though when "if mindshare is the criterion then Windows wins" moves past the conditional and assumes the position, it certainly becomes a boo-boo.

Re:defend his position that microkernels are crap? (1)

lp-habu (734825) | more than 8 years ago | (#15435224)

Fair enough, though when "if mindshare is the criterion then Windows wins" moves past the conditional and assumes the position, it certainly becomes a boo-boo.

My "ifs" never move past the conditional; they are very reliable; that's why I use them. :)

Re:Ignite the flames of the microkernel debate aga (1)

eLijahTheReticent (902423) | more than 8 years ago | (#15434500)

Its performance has nothing to do with being microkernel. TFA claims its better performance is because of the FASS [nicta.com.au] (Fast Address-Space Switching) technology that has been implemented on the Linux too. Its dependent on the ARM architecture and I guess is not applicable in other architectures.

Bad Second Link (4, Informative)

Ctrl+Alt+De1337 (837964) | more than 8 years ago | (#15434205)

Ignore the second link. The actual performance results are here [nicta.com.au] .

OT: Sig (0)

Anonymous Coward | more than 8 years ago | (#15435513)

Your sig says:

"New Godwin's Law: in internet discussions about G.W. Bush, over time probability of a mention of Orwell approaches one."

The only thing that makes Godwin's "law" the least bit interesting is the idea that any sufficiently long discussion will eventually include a comparison to Nazis (almost surely). In your version, it's not very interesting because you restricted it to a narrow set of topics (those concerning dubya). Saying, internet discussions about X will eventually mention Y isn't very profound, because X and Y may actually be related.

So, you could say "any sufficiently long discussion about genocide will eventually mention Nazis," and it wouldn't be very insightful. Whether you think the Bush administration is Orwellian, they certainly represent a very powerful government that has significantly expanded its powers, so there clearly is at least some relation to the topics Orwell was fond of. This is true even if you believe these actions were wise and reasonable and that we are still far from the extreme situations Orwell wrote about.

If all that was way too involved, let me make is short and sweet: Your sig is dumb.

This makes me wonder... (5, Interesting)

DaHat (247651) | more than 8 years ago | (#15434207)

Just how fast would a virtualized Linux instance running inside of a virtualized Linux instance running on hardware be?

Re:This makes me wonder... (5, Funny)

bazorg (911295) | more than 8 years ago | (#15434227)

Do you think that's air you're breathing now?

Re:This makes me wonder... (0)

Anonymous Coward | more than 8 years ago | (#15434289)

Obviously, faster than running virtualized Linux running inside of a Linux instance on hardware!

Re:This makes me wonder... ?? (1)

Nichole_knc (790047) | more than 8 years ago | (#15434395)

Yes it does make me wonder..... Running virtualized Linux on virtualized Linux hosted by Linux.... Now that seems to be just a bit overkill does it not....

Re:This makes me wonder... ?? (0)

Anonymous Coward | more than 8 years ago | (#15434422)

But... does it run Linux?

Re:This makes me wonder... ?? (3, Funny)

electr01nik (598106) | more than 8 years ago | (#15434535)

Yes it does make me wonder..... Running virtualized Linux on virtualized Linux hosted by Linux.... Now that seems to be just a bit overkill does it not....

Yeah but...imagine a Beowulf cluster of them!

Re:This makes me wonder... (1)

maxwell demon (590494) | more than 8 years ago | (#15434441)

Well, make that recursion infinite, and you'll get an infinitely fast Linux, and as a bonus you don't need hardware ay more, because beyond every layer of virtualized Linux there's yet another layer of virtualized Linux, ad infinitum. :-)

Re:This makes me wonder... (1)

johno.ie (102073) | more than 8 years ago | (#15434568)

But it would take forever to boot up

Re:This makes me wonder... (0)

Anonymous Coward | more than 8 years ago | (#15435509)

Nt really, cause you see.. the n-th layer would be so fast, that it would actually boot long before the top layers do.

ARM v4 or v5 processors only (5, Informative)

XoXus (12014) | more than 8 years ago | (#15434210)

The summary is misleading a bit - it's only faster on ARM v4 or v5 processors.

From TFA:

Wombat, NICTA's architecture-independent para-virtualised Linux for L4-embedded, can be faster than native Linux on the same hardware. Specifically on popular ARM v4 or v5 processors, such as ARM9 cores or the XScale, Wombat benefits from the fast address-space switch (FASS) technology implemented in L4-embedded, while this is not supported in native Linux distributions.

Only? (4, Interesting)

Anonymous Coward | more than 8 years ago | (#15434261)

I'm not sure if you realize the market penetration of ARM-based processors. They're basically everywhere. One popular use is in routers. Many printers also have ARM chips. They're also very widely used in cell phones and other mobile technology.

It benefits us all of more performance can be extracted from such chips, just because they're so widely used. Being able to get a greater degree of performance out of a device already in use can lead to lower-cost systems. To suggest that this is of limited use is naive, just because of how prevalent these processors are.

Re:Only? (5, Informative)

JanneM (7445) | more than 8 years ago | (#15434323)

It benefits us all of more performance can be extracted from such chips, just because they're so widely used.

The reaction is not against the performance but the disingenious presentation. A cursory reading makes it seem as if the performance gain was somehow tied to it being a microkernel, or that the virtualization step somehow magically speeded things up. It wasn't - their kernel is using some platform specific optimizations that Linux doesn't, that's all.

Re:Only? (2, Insightful)

maxwell demon (590494) | more than 8 years ago | (#15434361)

However that quote tells the reason for the performance boost: fast address-space switch (FASS) is supported in L4-embedded, but not in Linux native. IOW, it's not really "virtualized faster than native", but "using FASS faster than not using it". I guess you'd get even better performance if you'd make Linux native support FASS.

Re:ARM v4 or v5 processors only (0)

Anonymous Coward | more than 8 years ago | (#15434349)

The summary is misleading a bit ...

I'm guessing you're new here but this is quite common. =)

Re:ARM v4 or v5 processors only (2, Informative)

XoXus (12014) | more than 8 years ago | (#15434538)

Look at my user ID. I'm not new.

Actually, I spoke to some of the ERTOS people today. They're doing some interesting stuff, but like another poster has pointed out their focus is not speed, but reliability and "trustworthiness".

Informative? Only to those w/o senses of humor. (0)

Anonymous Coward | more than 8 years ago | (#15434927)

With an ID like that, you'd think you'd recognize an ancient Slashdot meme and just laugh.

Re:Informative? Only to those w/o senses of humor. (1)

Poltras (680608) | more than 8 years ago | (#15435297)

Respect the elders dude. Even more when you're a coward.

Faster and faster... (-1, Redundant)

kistel (585461) | more than 8 years ago | (#15434212)

I hope it runs faster and faster if you embed more and more layers of virtual machines! I'll never have to buy a newer processor again!

yeah, right (-1, Redundant)

l3v1 (787564) | more than 8 years ago | (#15434217)

I mean ok, it's nice, and it's an L4-kernel based os running faster on embedded platforms on ARM cpus than Linux kernel+os can. Yes, it's nice indeed. But neither the /. article title nor the summary does tell that.

Re:yeah, right (0)

Anonymous Coward | more than 8 years ago | (#15434307)

Well, if the summary and title told you everything, you wouldn't need to RTFA, would you? Lazy bastard, just click the link, RTFA, and stop whining.

Neato but... (2, Interesting)

tomstdenis (446163) | more than 8 years ago | (#15434226)

They sacrificed portability by performing some TLB caching hacks. It's a good idea but comparing it to Linux as a whole is a bad idea as Linux runs on more than the ARM they're testing on. If you look at all of the results most are comparable and exec/fork favour Linux.

Tom

Re:Neato but... (1)

SnowZero (92219) | more than 8 years ago | (#15434829)

Not to mention the null syscall is 5.7 times slower in the microkernel when compared to Linux. One might think that this would be a nonissue, but you'd be amazed how often server programs call "simple" syscalls such as gettimeofday.

Re:Neato but... (0)

Anonymous Coward | more than 8 years ago | (#15435088)

They sacrificed portability by performing some TLB caching hacks.

Not really, it seems to basically amount to using ASIDs, which Linux supports
on other architectures (including Alpha, powerpc, SPARC64, ia64).

Twice the buffering (3, Interesting)

jellomizer (103300) | more than 8 years ago | (#15434233)

It is possible. First you have drive access. Normally the data is buffered in memory then is paged out to the drive when the OS sees fit. When it is on the memory it can be accessed faster. So now you are virtualizing the hardware so when the OS says write to the Hard Drive it goes to the Host OS who then buffers it in memory and writes to the drive when it seems fit, so the files are buffered in memory for twice as long, allowing twice the time that it can access the faster data. Usually that is the largest slowdown on the system is drive access, also because when the host OS is writing to the drive the Virtualized Linux kernel is free to do what it wants. I am sure if the application requires a lot of interrupt calls or a lot of displaying to the screen it will slowdown (Unless the virtualized video drivers are much more optimized then the normal ones)
So it is possible, just as long as you have a system powerful enough to run both OSs well and with a lot of RAM.

Re:Twice the buffering (3, Informative)

tomstdenis (446163) | more than 8 years ago | (#15434272)

This is OT.

The speedup comes from TLB caching between processes. Not from "double caching".

In Linux when you switch processes the TLB is flushed [e.g. reloading CR3 on x86-*]. This is a safe [but slow] way to ensure your virtual memory for a given process is mapped correctly. I'm guessing [didn't fully read the linked research papers] that they share a virtual memory base between processes but map processes to different regions or something. Unless they have segment limits this will cause problems with process isolation.

For those not in the know, a TLB cache holds the translation of a virtual address into a physical one. Parsing a typical 32-bit address requires several layers [with 4KB pages it's four I think] of table lookup which is slow if you had to do it for every memory access. For example, take your 32-bit address, the lower 12 bits is the byte in a 4KB page, the next 10 bits points selects one 4KB page, the next 10 bits selects one 1024-entry array of pointers to 4KB pages. [iirc]. It's even worse in x86-64 mode as we are parsing a 48-bit virtual address.

So the processor will cache TLB lookups. When you switch processes you have to flush it because the translations don't map to your processes physicals memory.

Tom

Re:Twice the buffering (0)

Anonymous Coward | more than 8 years ago | (#15435275)

In Linux when you switch processes the TLB is flushed [e.g. reloading CR3 on x86-*]. This is a safe [but slow] way to ensure your virtual memory for a given process is mapped correctly.

No. All the world is not a 386. On many CPU architectures, Linux doesn't have to flush the
TLBs. PPC64 (POWER5+ as the world's fastest general purpose CPU being a prime implementation),
for example.

I'm guessing [didn't fully read the linked research papers] that they share a virtual memory base between processes but map processes to different regions or something. Unless they have segment limits this will cause problems with process isolation.

No, you use ASIDs.

Re:Twice the buffering (1)

tomstdenis (446163) | more than 8 years ago | (#15435419)

Technically on x86 you don't need to flush the TLB either. If you want you could just use upper bits as a PID. Specially on x86-64 where most processes use less tahn 24 bits of address space it'd be trivial to do that. Unfortunately, in long mode there are no segment limits on DS or CS which would mean you could pollute other processes. "segmentation" is provided by paging in x86-64 mode.

I'm just saying most OSes *do* that then optimize to avoid it where possible. So you really do need a fresh CR3 between processes. And you can't just hack some level of the page directory because the TLB wouldn't reflect the changes.

Tom
Tom

Re:Twice the buffering (1)

ettlz (639203) | more than 8 years ago | (#15434324)

This is interesting... quite often I've seen Windows XP start up faster under qemu than it would natively as Linux has kept an amount of the disk image in the cache. (Of course, if I start it from cold, it spends about 20 seconds just transferring a portion of the image into RAM, and then the rest of the startup is very quick.)

Re:Twice the buffering (1)

KiloByte (825081) | more than 8 years ago | (#15434426)

Also, a lot of software tends to sync after every write, believing that this is the holy grail for data consistency. This is not true, as losing power already pretty guarantees data loss. Plus, most hardware faults cause something worse than just a clean, nice instant shutdown. Having the disks synced won't save you from most motherboard glitches, a bit faulty memory, and so on. Plus, a sudden poweroff is something that can be easily handled with an UPS; there is no such easy way to ensure the rest of the hardware will work ok.

Thus, you need backups and fallover anyway.

So, why would we bother with an immense hit to performance just to be somewhat safer from a single type of hardware issues? Lying to Postgres about syncs will get you off that 100-200 transactions per second bottleneck, and lying to dpkg makes it install packages in a tiny fraction of second while a similar piece of hardware will take several seconds for the same task.

Of course, you do have to know what you're doing. There are pieces of data where you can/need to redo the failed run anyway, and there are financial transactions where losing committed data is unacceptable.

Re:Twice the buffering (1)

jilles (20976) | more than 8 years ago | (#15434576)

Or more general, virtualizing allows you to do dynamic optimizations in the interpretation of whatever virtualized API you are using. This how dynamically compiled Java can outperform statically compiled C for selected code fragments. This is also how HP showed a C vm outperforming compiled C on the same machine for selected programs. The vm could do optimizations at run time a compiler couldn't possibly do before run-time.

Native means performing according to whatever (naive) assumptions the compiler or programmer has to make about the run-time environment. Disk access is easy when your program is the only one talking to the drive. It's a different matter when there's hundreds of processes and thousands of threads from other programs are doing the same. That's why operating systems virtualize disk access and disks in turn also virtualize raw access to the disk platters (so your OS does not actually tell the disk when and how to position the heads). Disk performance would really suck without virtualization. So would writing any app that uses disks.

Hm (4, Informative)

FidelCatsro (861135) | more than 8 years ago | (#15434249)

Could it be because linux for ARM is not that well optimised . I can't imagine such massive performance gains otherwise , bar a massive bug in the kernel.

Fast Address-Space Switching for ARM Linux Kernels [nicta.com.au]

The Fast Address-Space Switching (FASS) project aims to utilise some of the features of the Memory Management Unit in the ARM architecture to improve the performance of context switches under the L4 kernel and ARM Linux.

Re:Hm (1)

BestNicksRTaken (582194) | more than 8 years ago | (#15434333)

Is FASS like "lazy task swapping" that you could turn off with the Intel StrongARM 233T, but not the earlier DEC StrongARM 200K/J?

I remember on RISC OS it was not turned off (on?) by default as it was pretty unstable.

Re:Hm (1)

pr0nbot (313417) | more than 8 years ago | (#15434488)

So, the benefits are because the virtualisation host OS provides better use of the underlying hardware than the corresponding Linux port.

Does this suggest an approach to Linux development whereby the Linux kernel is clean and abstract, and hardware idiosyncracies are handled by a virtualisation layer?

As always, I speak from a position of total ignorance.

I see SMOKE in the MIRRORS (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15434262)


I see the smoke in the mirrors, and it appears to be bullshit!

L4 deserves some attention (2, Insightful)

VincenzoRomano (881055) | more than 8 years ago | (#15434264)

I think that the whole L4 family [l4hq.org] smicrokernels hould deserve some more attention from IT professionals.
As far as I know L4 is one of the microkernels with more efforts for development. Along with MinixV3 [minix3.org] of course.

Re:L4 deserves some attention (1)

diegocgteleline.es (653730) | more than 8 years ago | (#15434362)

Sure it deserves attention, but what's the point of using L4 to run.....a monolithic kernel?

When running Linux under L4 (like in L4Linux), when the Linux process dies because of a bug, the system DIES. Sure, you can restart it, but so can you do in linux when something oopses using Kexec.

L4 was written to run real microkernels on top of it. If you want to run Linux instances so that a crash of the kernel doesn't crash the system, you'd surprised to know that Linux already includes in it's heart a vm-ish/microkernel-ish approach: Xen.

Architecture dependent outperforms? (1)

VincenzoRomano (881055) | more than 8 years ago | (#15434269)

Are those winning performances valid also outside the embedded world?
I fear that Linux running over a "normal" x86 CPU outperferms almost everything else.

Re:Architecture dependent outperforms? (1)

VincenzoRomano (881055) | more than 8 years ago | (#15434286)

In any case, as there are more embedded devices willing to run opensource software than PCs and servers, I'd say that those [nicta.com.au] results are very good [nicta.com.au] !
And maybe there will be a way to embed that technology [nicta.com.au] into Linux!

What about Exokernels? (0)

Anonymous Coward | more than 8 years ago | (#15434299)

Why is it that you only hear about microkernels and monolithic kernels? I want an exokernel based OS dammit!

http://pdos.csail.mit.edu/exo.html [mit.edu]

Re:What about Exokernels? (2, Interesting)

akheron01 (637033) | more than 8 years ago | (#15434435)

screw that! give me a kernel-less OS! check out KLOS

More Information Needed... (0)

Anonymous Coward | more than 8 years ago | (#15434328)

Well I only browsed through the article but more information would have been welcome... what architecture does it support, how does it compare to Xen [cam.ac.uk] and other similar products, where do you download it, what license is it under, can I run it on my toaster, and most importantly how long does it take to complete an infinite loop?

Pet maths peeve (2, Interesting)

Emil Brink (69213) | more than 8 years ago | (#15434350)

The performance results [nicta.com.au] page states:

The result is that context-switching costs of virtualised Linux are up to thirty times less than in native Linux.

(Emphasis in the original text). This is one of my pet peeves, since I think it's so sloppy use of maths. How can something be "thirty times less?" So, if it takes one second in Linux, it takes them ... what? 1 - 30 * 1 = -29 seconds? I guess they mean 1/30:th of a second, but still, that should have been caught before being published, imo. Or maybe it's just because I'm not a native speaker of English, that it annoys me so.

Re:Pet maths peeve (1)

Covener (32114) | more than 8 years ago | (#15434433)


How can something be "thirty times less?" So, if it takes one second in Linux, it takes them ... what? 1 - 30 * 1 = -29 seconds?


Definitely a problem with your interpretation of the english. "smaller by 30 times", "smaller by a factor of 30".

The "less" there isn't read as a (subtraction) operator.

Re:Pet maths peeve (0)

Anonymous Coward | more than 8 years ago | (#15434462)

I can understand your perspective on this.

Still, it rolls off the tongue better than one-thirtieth. And the "thirty times" is clear in conveying the ratio, while the "less" is clear in conveying the idea of reduction. So, it doesn't annoy me at all because the meaning and the english are clear, unambiguous and established.

My pet peeve is those idiots who say something like "he was driving at a high rate of speed".

*That* really makes me wince.

The correct phrase: "he was driving at high speed" is not just technically correct, but clearer and easier to say.

Re:Pet maths peeve (0)

Anonymous Coward | more than 8 years ago | (#15434983)

It would also be ok to say "he was consuming speed at a high rate."

Re:Pet maths peeve (1)

westyx (95706) | more than 8 years ago | (#15434522)

It takes one-thirtieth (1/30 times x, where x is the time normally taken) the time.

Yeah, english is like that.

Re:Pet maths peeve (1)

bogado (25959) | more than 8 years ago | (#15434571)

Well the problem isn't the math on the article, the problem is that you're trying to parse a natural language statement with a mathematical mindset. Mathematical texts, proofs and literature in general is written in a very concise and with great attention to the precision of what is being stated, and it is read in the same way, with every step being dissected and followed precisely.

Natural language don't have those requirements, it's intention is to communicate an idea and if this is successfully it don't matter how precise the idea is being stated. In the phrase above you got the idea, and I suppose you could, as I got, even learned more then simpe number.

The use of "up to", makes an idea that this value (30 times less) is in fact the best that it could do, this makes this final result more or less useless, when does this reach this levels? How often does this virtualization scheme gets to this 30 times speed up? My guess is that this is a highly specialized result that can only be achieved in testing environments, otherwise they would have used a wording like "consistently reaches 30 times less" or "it is 30 times less in average", simply because it sounds better.

Well, analyzing the hole result one can clearly sees that the message is clear and could be written in one sentence: "We feel that this solution is better, faster and cooler then Linux, use it now". They throw a few technical reasons to support and make a extraordinary claim with the best numbers they could crush. Now, I am not stating that this virtualization sucks or that they are being sneaky, this is a common tatics after all "up to 30 times less" is much better then the real mean multiplier and they are trying to make people see their otherwise unknown product, what better way then comparing with the product everyone knows and love?

Re:Pet maths peeve (1)

petermgreen (876956) | more than 8 years ago | (#15434834)

sloppy maths or not its the normal way of saying it in english.

Re:Pet maths peeve (1)

Surt (22457) | more than 8 years ago | (#15435435)

That's definitely common english usage, meaning:
  30 * virtualized = native

As somebody familiar with the project (4, Informative)

agent dero (680753) | more than 8 years ago | (#15434360)

I've been researching more and more into NICTA's microkernel and virtualization (for my L4::BSD [google.com] idea) and one thing that is important to understand is that NICTA's development is mainly on ARM, the Kenge toolset, as well as the Iguana OS are both much further along on ARM as opposed to i386

Considering the work that NICTA does with companies that produce embedded hardware like Qualcomm [nicta.com.au] , this isn't surprising, but don't go crazy about this.

Linux development is much more fine tuned on x86, and Kenge/Iguana development is much more fine tuned on ARM; no need to start holy wars here ;)

That said, nice work benno, chuck, and gernot (and whomever else I'm forgetting)

Wombat (0, Redundant)

nighty5 (615965) | more than 8 years ago | (#15434380)

I love the name, being an Aussie I can see the amusing side.

For those of us who arent Australian, a Wombat is an native Australian marsupial.

The wombat has powerful burrowing techniques. I'm wondering if they chose the name because of the nature of virtualisaton and how it burrows metaphorically into the O/S.

Re:Wombat (1)

ozmanjusri (601766) | more than 8 years ago | (#15434461)

I'm wondering if they chose the name because of the nature of virtualisaton and how it burrows metaphorically into the O/S.

Considering the sense of humour normally displayed by these guys, it's more likely to be because the wombat eats roots and leaves.

Re:Wombat (1)

SiggyTheViking (890997) | more than 8 years ago | (#15434737)

Where I come from wombat stands for
Waste
Of
Money,
Brains,
And
Talent

Completely misleading article submitted (0)

Anonymous Coward | more than 8 years ago | (#15434381)

Please kill the submitter. The article summary is just misleading. They did not virtualize linux and gain a speedup, instead they hacked the context switching code to use a cpu native feature to gain the speedup.

Also please kill the poster who simply didn't read the article at all to discover the flaw.

Re:Completely misleading article submitted (1)

Patrik_AKA_RedX (624423) | more than 8 years ago | (#15434544)

Both have been taken out and shot.
Do you wish to receive their heads on a stainless steel spear?

IME WINE was faster than native MS Windows (1)

fatphil (181876) | more than 8 years ago | (#15434415)

Not hugely, perhaps 0.3%, but it was consistently faster for what I was doing. I put it down simply to having a better scheduler, and less cache trashing on task switches, or some other voodoo like that.

So such paradoxes are far from unusual.

Of course, we could combine these two improvements...

FatPhil

A new form of energy (3, Funny)

waif69 (322360) | more than 8 years ago | (#15434440)

If one were to use 33 levels of virtualization on the ARM processor, the efficiency is so great that power may be removed and the system runs on its own efficiency. Yeah! We don't need oil anymore.

Time to cue up some U2 (3, Funny)

pmbuko (162438) | more than 8 years ago | (#15434443)

Even better than the real thing....

Re:Time to cue up some U2 (3, Funny)

datafr0g (831498) | more than 8 years ago | (#15434504)

This virtualized Linux moves in mysterious ways, but I still haven't found what I'm looking for.

Re:Time to cue up some U2 (1)

Dareth (47614) | more than 8 years ago | (#15434976)

Just another manic monday... *oh hell, damn that woman and her 80's music* ... I mean Sunday, Bloody Sunday!

but... (0)

Anonymous Coward | more than 8 years ago | (#15434582)

but... does it run linux??

The more microkernels the better? (3, Funny)

mikael (484) | more than 8 years ago | (#15434723)

^switch writes "Aussies at NICTA have developed a para-virtualized Linux called Wombat that they claim outperforms native Linux.

So if a para-virtualised microkernel runs a para-virtualised microkernel running Linux, then there should be an even greater speedup?

Strange (3, Insightful)

Sgt Pinback (118723) | more than 8 years ago | (#15434788)

So, what are they trying to show? "Because we've implemented support for a certain MMU feature and native Linux hasn't, we've demonstrated that virtualizing Linux on L4 is a good idea"? Doesn't sound perfectly logical to me. Apples and oranges come to mind.

Cool BIOS (0, Offtopic)

sgt scrub (869860) | more than 8 years ago | (#15435063)

It's about time someone wrote a bios that lets Linux shine.

Welcome (3, Funny)

Anonymous Coward | more than 8 years ago | (#15435312)

I for one welcome our new Fast Address-Space Switching overlords!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>