Slashdot Mirror


Virtualized Linux Faster Than Native?

^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.

39 of 153 comments (clear)

  1. Curious warning on the website by LiquidCoooled · · Score: 5, Funny

    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

    --
    liqbase :: faster than paper
    1. Re:Curious warning on the website by Rorian · · Score: 5, Funny

      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.

      --
      Will program for karma.
    2. Re:Curious warning on the website by AndroidCat · · Score: 2, Funny
      "The other day I put instant coffee in my microwave oven ... I almost went back in time." -- Steven Wright

      Important safety tip, thanks Egon.

      --
      One line blog. I hear that they're called Twitters now.
  2. Ignite the flames of the microkernel debate again? by Enderandrew · · Score: 2, Interesting

    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.

    --
    http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
  3. Bad Second Link by Ctrl+Alt+De1337 · · Score: 4, Informative

    Ignore the second link. The actual performance results are here.

  4. This makes me wonder... by DaHat · · Score: 5, Interesting

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

    1. Re:This makes me wonder... by bazorg · · Score: 5, Funny

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

    2. Re:This makes me wonder... by Hitch · · Score: 4, Funny

      so...it's actually *penguins* all the way down?

      --
      You see, without that little doohicky, the universe stops.
      http://propheteer.org
  5. ARM v4 or v5 processors only by XoXus · · Score: 5, Informative

    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.

    1. Re:ARM v4 or v5 processors only by master_p · · Score: 2

      Microkernels will not come of age until CPUs support true modularization. Previously on /. :

      http://linux.slashdot.org/comments.pl?sid=185800&c id=15341069

    2. Re:ARM v4 or v5 processors only by XoXus · · Score: 2, Informative

      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".

  6. Neato but... by tomstdenis · · Score: 2, Interesting

    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

    --
    Someday, I'll have a real sig.
  7. Twice the buffering by jellomizer · · Score: 3, Interesting

    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.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:Twice the buffering by tomstdenis · · Score: 3, Informative

      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

      --
      Someday, I'll have a real sig.
  8. Hm by FidelCatsro · · Score: 4, Informative

    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

    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.

    --
    The only things certain in war are Propaganda and Death. You can never be sure which is which though
  9. Only? by Anonymous Coward · · Score: 4, Interesting

    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.

    1. Re:Only? by JanneM · · Score: 5, Informative

      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.

      --
      Trust the Computer. The Computer is your friend.
    2. Re:Only? by maxwell+demon · · Score: 2, Insightful

      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.

      --
      The Tao of math: The numbers you can count are not the real numbers.
  10. L4 deserves some attention by VincenzoRomano · · Score: 2, Insightful

    I think that the whole L4 family 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 of course.

    --
    Maybe Computers will never be as intelligent as Humans.
    For sure they won't ever become so stupid. [VR-1988]
  11. Re:defend his position that microkernels are crap? by AKAImBatman · · Score: 3, Informative

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

    QNX

    'Nuff said.

  12. KLAATU... VERATA... by dsginter · · Score: 4, Funny

    NICTA... necktie...

    Definitely an n-word.

    --
    More
  13. Re:defend his position that microkernels are crap? by diegocgteleline.es · · Score: 2, Interesting

    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.

  14. Pet maths peeve by Emil+Brink · · Score: 2, Interesting
    The performance results 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.
    --
    main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
    1. Re:Pet maths peeve by nuzak · · Score: 2, Insightful

      It's mathematically and grammatically quite sound: if X is 30 times more than Y, then Y is 30 times less than X.

      --
      Done with slashdot, done with nerds, getting a life.
  15. As somebody familiar with the project by agent+dero · · Score: 4, Informative

    I've been researching more and more into NICTA's microkernel and virtualization (for my L4::BSD 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, 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)

    --
    Error 407 - No creative sig found
  16. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

  17. A new form of energy by waif69 · · Score: 3, Funny

    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.

  18. Time to cue up some U2 by pmbuko · · Score: 3, Funny

    Even better than the real thing....

    1. Re:Time to cue up some U2 by datafr0g · · Score: 3, Funny

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

      --
      "Who says nothing is impossible? Some people do it every day!" - Alfred E. Neuman
  19. Re:defend his position that microkernels are crap? by lp-habu · · Score: 2, Insightful
    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.

  20. Re:This makes me wonder... ?? by electr01nik · · Score: 3, Funny
    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!

  21. Re:defend his position that microkernels are crap? by diegocgteleline.es · · Score: 2, Insightful

    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

  22. The more microkernels the better? by mikael · · Score: 3, Funny

    ^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?

    --
    Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  23. Strange by Sgt+Pinback · · Score: 3, Insightful

    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.

    --

    --

    I do not like the men on this space ship!
  24. Re:defend his position that microkernels are crap? by RedDirt · · Score: 2, Insightful

    > 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, (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.

    --
    James
  25. Re:defend his position that microkernels are crap? by AKAImBatman · · Score: 2, Informative

    Free (as in soda pop)

    'Nuff said.

  26. Welcome by Anonymous Coward · · Score: 3, Funny

    I for one welcome our new Fast Address-Space Switching overlords!

  27. Re:Ignite the flames of the microkernel debate aga by hey! · · Score: 3, Interesting

    Last time I read Linus talking about microkernels, it was a lot more nuanced than "Microkernels are crap". It was more along the lines that microkernel architectures end up with greater complexity and more comunication overhead at higher levels. It certainly leaves open the possiblity that a particular microkernel could be fast at a particular set of operations.

    What's interesting about a what we're apparently talking here is a virtualized linux running on top of a microkernel. I'm reasonably certain that they didn't do a complete reengineering of Linux as a microkernel, they just got it to run on top of a microkernel. So, we're still talking about a monolithic kernel with all kinds of tight coupling, but the virutalized hardware can make certain hardware related tasks faster. In particular they talk about context switches being much faster; since the microkernel is specifically designed for single architecture (ARM), it may not be so surprising that they can take better advantage of certain architectural features.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  28. Re:Informative? Only to those w/o senses of humor. by Ryan+Amos · · Score: 3, Funny

    Please.

    A low slashdot id just means you've been heaping shit on the pile longer than anyone else.