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.

9 of 153 comments (clear)

  1. Bad Second Link by Ctrl+Alt+De1337 · · Score: 4, Informative

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

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

  3. 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
  4. 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.
  5. 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.

  6. 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.
  7. 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
  8. Re:defend his position that microkernels are crap? by AKAImBatman · · Score: 2, Informative

    Free (as in soda pop)

    'Nuff said.