Slashdot Mirror

← Back to Stories (view on slashdot.org)

Virtualized Linux Faster Than Native?

Posted by ryuzaki0 on from the too-specialized-to-count dept.

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

153 comments

  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.
    3. Re:Curious warning on the website by agent+dero · · Score: 1

      NICTA is pretty good about a sense of humour, in one of their Darbat 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.

      --
      Error 407 - No creative sig found
    4. Re:Curious warning on the website by Anonymous Coward · · Score: 0

      So it's essentially a Quantum computer?

    5. Re:Curious warning on the website by Anonymous Coward · · Score: 0

      Well, they say it was.

    6. Re:Curious warning on the website by LifesABeach · · Score: 1

      It is amazing, with enough Fosters, one can see AnyThing.

    7. Re:Curious warning on the website by I+Like+Pudding · · Score: 1

      ETROS and NICTA will not be held responsible for any resulting time paradoxes.

      No wonder you got the first post

    8. Re:Curious warning on the website by lewi · · Score: 1

      "time paradoxes?"

      So does this make the resultant OS precognitive multitasking?

    9. Re:Curious warning on the website by Anonymous Coward · · Score: 0

      Stephen Hawking? Is that you?

  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?

    --
    Help Brendan pay off his student loans
    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 Anonymous Coward · · Score: 0

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

    3. Re:This makes me wonder... by maxwell+demon · · Score: 1

      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. :-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
    4. Re:This makes me wonder... by johno.ie · · Score: 1

      But it would take forever to boot up

      --
      872835240
    5. Re:This makes me wonder... by Anonymous Coward · · Score: 0

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

    6. 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
    7. Re:This makes me wonder... by fbg111 · · Score: 1

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

      Hey, a new cs field is born - optimization by infinite recursion of paravirtualized Linux instances.

      --
      Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
    8. Re:This makes me wonder... by Anonymous Coward · · Score: 0

      I don't know who modded this overrated, but they're terminally stupid. This is the funniest thing I've seen on Slashdot in months. Priceless.

    9. Re:This makes me wonder... by Anonymous Coward · · Score: 0

      Quick! Somebody tell Terry Pratchett!

  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 Anonymous Coward · · Score: 0
      The summary is misleading a bit ...

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

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

    3. 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.
    1. Re:Neato but... by SnowZero · · Score: 1

      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.

    2. Re:Neato but... by Anonymous Coward · · Score: 0

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

    3. Re:Neato but... by 0xABADC0DA · · Score: 1

      They did not sacrifice portability to get this result, it's the whole point of having a tiny microkernel like L4 in the first place. Since the microkernel is so small you can just rewrite it for each hardware type from scratch. You can add a new HAL to linux with some assembly code, but Linux makes a lot of assumptions about how the vm and such work that make it hard to do it the optimal way for some hardware.

    4. Re:Neato but... by Anonymous Coward · · Score: 0

      > you'd be amazed how often server programs call "simple" syscalls such as gettimeofday.

      In a microkernel, this is not a syscall, and there's no ring traversal. A regular context switch is a lot faster.

    5. Re:Neato but... by renoX · · Score: 1

      >They sacrificed portability by performing some TLB caching hacks.

      That's a biased way of reporting what they did: they used platform specific optimisation, Linux does it also quite often but the Linux kernel tested doesn't have this particular optimisation.

  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.
    2. Re:Twice the buffering by ettlz · · Score: 1

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

    3. Re:Twice the buffering by KiloByte · · Score: 1

      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.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    4. Re:Twice the buffering by jilles · · Score: 1

      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.

      --

      Jilles
    5. Re:Twice the buffering by Anonymous Coward · · Score: 0

      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.

    6. Re:Twice the buffering by tomstdenis · · Score: 1

      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

      --
      Someday, I'll have a real sig.
    7. Re:Twice the buffering by Anonymous Coward · · Score: 0

      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.

      No, you can't because we're talking about switching address spaces in a protected memory
      operating system. You may be able to do some segmentation hacks, but I'm not sure that would
      be any faster on on modern CPUs.

      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.

      That's why you tag the TLB with ASIDs.

    8. Re:Twice the buffering by kscguru · · Score: 1

      AMD's x86-64 does have segment limits (RevD and later), at the request of VMware. Also, AMD's Pacifica introduces ASIDs (Address Space IDs) into the TLB (RevF and later). It's x86, finally learning from all the other processors out there...

      --

      A witty [sig] proves nothing. --Voltaire

    9. Re:Twice the buffering by bgamsa · · Score: 1

      Actually, most of the performance benefit presumably comes from the fact that most ARM cores use virtually indexed caches, which uses the virtual address instead of the physical address to do cache lookups (thus bypassing the TLB altogether in most cases). As a result, on a context switch, you need to flush the cache as well as the TLB. There are extra facilities available that allow for the segregation of multiple addresses spaces, but they impose restrictions on the process address space and/or the number of processes. If you can live with those restrictions (or if you are willing to make major changes to the Linux kernel) you can avoid the cache flushes and hence get massive context switch speedups.

  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
    1. Re:Hm by BestNicksRTaken · · Score: 1

      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.

      --
      #include <sig.h>
    2. Re:Hm by pr0nbot · · Score: 1

      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.

    3. Re:Hm by drinkypoo · · Score: 1

      It's not a particularly easy thing to do but it has definitely been done before - over and over again. In particular the best-known case of this is the AS/400, whatever the hell they call it now (iSeries maybe?) AS/400 systems used to have a very wonky processor, and ever since they've been putting these hardware/firmware bytecode translators between the OS and the CPU to the point where AS/400 systems now use PowerPC or POWER processors (forget which) and they have this thing stuck on the front that translates the bytecode. The benefit? Binary code from the early days STILL works. AS/400 also has numerous other benefits, like being able to link together object modules from different languages into a single executable - although I'm sure the terminology is some wonky IBM thing that's totally different from that.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:Hm by Bozdune · · Score: 1

      Interestingly, some tidy fortunes have been made by small shops building useful AS/400 applications. Those beasts never die.

      At one time, this was a sure way to make money:

      1. Find a hot-selling and useful business app that only runs on some other hardware, say x86.
      2. Invest the time and patience to wade through 9,000 pages of obscure IBM wonkery ("those guys have a different word for EVERYTHING"), enough time at least to create a reasonable development environment for yourself.
      3. Code the app.
      4. Profit.

      May still be, for all I know.

    5. Re:Hm by FnH · · Score: 1

      Last name I heard was System i5 They use POWER5 processors The wonky IBM term is Integrated Language Environment

  9. defend his position that microkernels are crap? by smittyoneeach · · Score: 1

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

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    1. 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.

      --
      Javascript + Nintendo DSi = DSiCade
    2. 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.

    3. Re:defend his position that microkernels are crap? by Wdomburg · · Score: 1

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

    4. Re:defend his position that microkernels are crap? by alexhs · · Score: 1

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

      --
      I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
    5. Re:defend his position that microkernels are crap? by bhirsch · · Score: 1

      Traffic lights != tons of web servers...

    6. Re:defend his position that microkernels are crap? by Anonymous Coward · · Score: 0

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

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

    8. Re:defend his position that microkernels are crap? by DrSkwid · · Score: 1

      300+ syscalls, how hard can it be?

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    9. Re:defend his position that microkernels are crap? by LurkerXXX · · Score: 1

      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.

    10. Re:defend his position that microkernels are crap? by smittyoneeach · · Score: 1

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

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    11. 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

    12. Re:defend his position that microkernels are crap? by lp-habu · · Score: 1
      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.

    13. Re:defend his position that microkernels are crap? by Deliveranc3 · · Score: 1

      NOT FREE.
      'Nuff said.

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

      Free (as in soda pop)

      'Nuff said.

      --
      Javascript + Nintendo DSi = DSiCade
    16. Re:defend his position that microkernels are crap? by Anonymous Coward · · Score: 0

      Retard.

    17. Re:defend his position that microkernels are crap? by Poltras · · Score: 1

      Insensitive Clod.

      --
      Of Code And Men
    18. Re:defend his position that microkernels are crap? by smittyoneeach · · Score: 1

      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.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    19. Re:defend his position that microkernels are crap? by lp-habu · · Score: 1
      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. :)

    20. Re:defend his position that microkernels are crap? by Nevyn · · Score: 1

      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.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    21. Re:defend his position that microkernels are crap? by DrSkwid · · Score: 1

      37

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    22. Re:defend his position that microkernels are crap? by Anonymous Coward · · Score: 0

      Plan 9 solves all those problems in a sane way and its only got 28 syscalls.

    23. Re:defend his position that microkernels are crap? by halfcuban · · Score: 1

      So now the relevancy of a OS' design is decided by its mindshare? Bumpkis. While one can argue the merits of a well crafted OS that has little to no applications, the theoretical arguments are still just as valid and just as relevent. Arguing the merits of a systems design vis a vis how much marketshare it has is ridiculous, just like saying MS has better designed OS just because it rules the roost.

    24. Re:defend his position that microkernels are crap? by miro+f · · Score: 1

      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.

      actually he only needed to do one of those things =)

      --
      being vague is almost as cool as doing that other thing...
  10. 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.
    3. Re:Only? by commanderfoxtrot · · Score: 1

      Exactly.

      It's not "Linux is bad" just that they're using specific optimisations which haven't been realised in Linux.

      Can anyone tell me where these would be applied? In GCC? In the Kernel? Stop using precompiled kernels? :-)

      --
      http://blog.grcm.net/
    4. Re:Only? by HeroreV · · Score: 1

      Why on earth isn't it already? I thought Linux was suppossed to be the "super mega ultra amazing bestest thing ever ever ever in the entire multiverse ever OMG it's so awesome Linux is the best Linux makes me horny Linux is God in kernel form *hyperventilate* I wish I could marry Linux for real cause it's so really really cool". If Linux is really as great as so many people think it is, shouldn't something like this already be in there?

  11. 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]
    1. Re:L4 deserves some attention by diegocgteleline.es · · Score: 1

      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.

    2. Re:L4 deserves some attention by VincenzoRomano · · Score: 1
      what's the point of using L4 to run.....a monolithic kernel?
      To run more than one monolithic kernel at once!

      --
      Maybe Computers will never be as intelligent as Humans.
      For sure they won't ever become so stupid. [VR-1988]
    3. Re:L4 deserves some attention by HuguesT · · Score: 1

      The point is that you can run a comfy linux environment on your CPU, which is useful for things like editors and compilers, while you are developing some L4-reliant RT software.

      Linux runs like some kind of background task, and so won't disturb the RT tasks.

    4. Re:L4 deserves some attention by diegocgteleline.es · · Score: 1

      Again, use Xen for that. It works today.

  12. Architecture dependent outperforms? by VincenzoRomano · · Score: 1

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

    --
    Maybe Computers will never be as intelligent as Humans.
    For sure they won't ever become so stupid. [VR-1988]
    1. Re:Architecture dependent outperforms? by VincenzoRomano · · Score: 1

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

      --
      Maybe Computers will never be as intelligent as Humans.
      For sure they won't ever become so stupid. [VR-1988]
  13. What about Exokernels? by Anonymous Coward · · Score: 0

    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

    1. Re:What about Exokernels? by Anonymous Coward · · Score: 0

      Plan 9 from Bell Labs is the closest you are going to get that is usable for awhile. With only 28 ioctl most of the calls are libary calls. It is the most hybrid of all the kernels out there. Using solely one method for everything is not always good because sometimes other methods are simplier/faster/require less instructions/etc.

    2. Re:What about Exokernels? by djs98052 · · Score: 1

      Over the years, I have often thought that if we want the most stable operating system, we should write one based on the mouse driver. It seems like no matter how hosed the operating system is, the mouse continues to function properly and moves about the screen.

    3. Re:What about Exokernels? by BiggerIsBetter · · Score: 1

      I got a little bit excited reading that. Is this the Next Big Thing?

      --
      Forget thrust, drag, lift and weight. Airplanes fly because of money.
  14. Re:yeah, right by Anonymous Coward · · Score: 0

    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.

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

    NICTA... necktie...

    Definitely an n-word.

    --
    More
  16. More Information Needed... by Anonymous Coward · · Score: 0

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

  17. 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 Covener · · Score: 1

      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.
    2. Re:Pet maths peeve by Anonymous Coward · · Score: 0

      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.

    3. Re:Pet maths peeve by westyx · · Score: 1

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

      Yeah, english is like that.

    4. Re:Pet maths peeve by bogado · · Score: 1

      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?

      --
      []'s Victor Bogado da Silva Lins

      ^[:wq

    5. Re:Pet maths peeve by petermgreen · · Score: 1

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

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    6. Re:Pet maths peeve by Anonymous Coward · · Score: 0

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

    7. Re:Pet maths peeve by Surt · · Score: 1

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

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    8. 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.
    9. Re:Pet maths peeve by try_anything · · Score: 1

      Your annoyance is completely justified. When reading technical writing, it often happens that what appears to be a poorly written passage turns out to be a very carefully written passage that reveals something the reader did not previously understand. For this reason, readers of technical material do not gloss over sloppy usage as quickly as casual speakers and readers do. Instead, they try to puzzle meaning out of it. Technical writers should keep that in mind and write documents that repay careful reading, rather than punishing it by forcing readers to carefully pick through one sloppy phrase after another.

      The only role your lack of native English played here was that it may have taken you a few seconds longer to identify the problem as bad writing rather than misunderstanding on your part.

  18. 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
  19. Wombat by nighty5 · · Score: 0, Redundant

    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.

    1. Re:Wombat by ozmanjusri · · Score: 1
      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.

      --
      "I've got more toys than Teruhisa Kitahara."
    2. Re:Wombat by SiggyTheViking · · Score: 1

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

  20. Completely misleading article submitted by Anonymous Coward · · Score: 0

    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.

    1. Re:Completely misleading article submitted by Patrik_AKA_RedX · · Score: 1

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

  21. Re:This makes me wonder... ?? by Nichole_knc · · Score: 1

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

  22. IME WINE was faster than native MS Windows by fatphil · · Score: 1

    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

    --
    Also FatPhil on SoylentNews, id 863
  23. Re:This makes me wonder... ?? by Anonymous Coward · · Score: 0

    But... does it run Linux?

  24. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

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

  26. 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
    2. Re:Time to cue up some U2 by Dareth · · Score: 1

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

      --

      I only look human.
      My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
  27. Re:Ignite the flames of the microkernel debate aga by eLijahTheReticent · · Score: 0

    Its performance has nothing to do with being microkernel. TFA claims its better performance is because of the FASS (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.

  28. 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!

  29. but... by Anonymous Coward · · Score: 0

    but... does it run linux??

  30. 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
  31. 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!
    1. Re:Strange by General+Lee's+Peking · · Score: 1

      I haven't found any explicit statement of why they're virtualizing Linux, but from looking at this page, it would appear to me that this about developing Iguana. That is, if Iguana is for providing OS services on the L4 microkernel, what better way to develop and test it than actually using it for virtualizing an existing OS interface? And considering the existing software available for it, what better OS than Linux? I don't know very much about this, but I doubt virtual Linux on L4 is intended to be an end in itself. Even so, if its performance or a significant part of its performance approaches, meets, or exceeds that of Linux, it demonstrates success in the progress in the development of Iguana, whether that's their intention or not. I think that alone is interesting.

  32. Informative? Only to those w/o senses of humor. by Anonymous Coward · · Score: 0

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

  33. Cool BIOS by sgt+scrub · · Score: 0, Offtopic

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

    --
    Having to work for a living is the root of all evil.
  34. Re:Informative? Only to those w/o senses of humor. by Poltras · · Score: 1

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

    --
    Of Code And Men
  35. Welcome by Anonymous Coward · · Score: 3, Funny

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

  36. OT: Sig by Anonymous Coward · · Score: 0

    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.

  37. 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.
  38. Oh Dear by Anonymous Coward · · Score: 0

    Womabats and iguanas living together?
    Sounds unholy.

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

  40. Re:Informative? Only to those w/o senses of humor. by drinkypoo · · Score: 1

    Not to mention someone occasionally sells one on ebay...

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  41. Good to see anyway! by Eli+Gottlieb · · Score: 1

    Nice to know somebody has implemented a processor feature to help microkernels switch address spaces quickly!

  42. I call BS by /dev/trash · · Score: 1

    Bullshit.

    1. Re:I call BS by BaseLineNL · · Score: 1

      BS is Bullshit? Man, I always wondered why people would call a Bachelor of Science so much.

  43. Even on ARM4/5 it's a bit slower by billstewart · · Score: 1
    Go read the article again (the article with the actual numbers). Yes, there are lots of functions for which the Virtual version is a lot faster, at least on the ARM platforms, so there may be specific kinds of applications where it really rocks - I'd look at routing and real-time control.

    But the AIM7 benchmark, which models typical general-purpose Unix system usage, has consistently faster results for regular Linux than for the Wombat virtualized version, even though there may be individual functions that are faster. The cool thing, though, is that the performance hit is only about 2-3% - not bad at all for a microkernel with some provable security and reliability features.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  44. RTFA - Wombat is slightly slower, not much faster by billstewart · · Score: 1

    RTFA again. Wombat isn't a "massive performance gain", though there are some functions for which it's several times faster and therefore there may be some real-world applications for which it could be faster. If you look at the AIM7 benchmarks, which are modeling average workloads for a typical Unix system, Wombat was actually 2-3% slower than Linux, in spite of having those functions go faster. That's still really pretty good, given the reputation for slowness than microkernels have. If they can port those optimizations to Linux, then maybe Linux would be even faster.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  45. Re:Informative? Only to those w/o senses of humor. by booch · · Score: 1

    Or it could mean that we've been here so long, we remember what's under the pile of shit.

    --
    Software sucks. Open Source sucks less.
  46. Hmm, anyone else? by Anonymous Coward · · Score: 0

    Anyone else see 'FASS technology' and think ... Fast Ass Technology.

    It looks like someone wanted to use that internal speak and had to invent a commercial speak version, Fast Address-Space Switching.

    Pity. I think they could have run with the Fast Ass Technology moniker.

  47. Article Incorrect by Anonymous Coward · · Score: 0

    Nothing is faster than a native. :)

  48. Microkernels by Anonymous Coward · · Score: 0

    Sounds like another round of micro vs monolithic kernel debates is about to fire up. Prepare for Linus to start talking shit *ducks*

    On a side note this is really old news.

  49. It is interesting but by LWATCDR · · Score: 1

    Seems to me that native Linux would out perform virtualised Linux if they modified Linux to use the same fast address-space switch that L4 does with running on the ARM.
    Now if I could just get a PC that used 4 ARM cores running at 2+Ghz with a good floating point.

    I would love to see a real speed ARM system. Now that Apple has gone over to Intel my hopes of an X86 free life seem more and more distant.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  50. Re:Informative? Only to those w/o senses of humor. by Anonymous Coward · · Score: 0

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

    1) Users with low UIDs like to boast about their age and crustiness
    2) "You must be new here" is not limited to /.
    3) Like all stupid cliches, it's overused and therefore not funny except to the LCD
    4) Only morons use the term "meme" in sentences

  51. So? Virtual WinXP faster than native on iMac Duo by lpq · · Score: 1

    May or not be the same thing...but a month or so ago, Anandtech sported a review of the new Apple Intel Core Duo and ran benchmarks on "BootCamp" (native XP with Apple hardware drivers) vs. using a virtual PC technology from Parallel and Parallel or MS-Generic Drivers.

    Tests showed the Virtual PC ran consistently faster than "BootCamp" except on a disk-heavy Multimedia benchmark and even there, the virtual PC was only about 2% slower.

    So tell me, how does a Virtual machine run faster than Native?

    It looked like the "BootCamp" hardware drivers were stealing cycles from compute-bound tasks, making native performance run slower than virtualized performance. The virtual emulated disk, however, was too much of a performance hit to be compensated for by Apple's lower-performance drivers.

    Just a guestimate, but it looks like Apple's HW drivers degrade performance by about
    10-15% versus "normal" drivers.

    On this page, the numbers show the iMac Core Due@ 2GHz performing ~15% slower than a 1.86GHz, Generic-PC Core Duo.

    It's better than the 3-5X performance hit the Apple G5 had on server tasks versus Linux 2.6.

    Even having the advantage of running on the same hardware as on the iMac, Apple OS
    needs some signifcant tuning.

    The performance "dehanced" drivers under "BootCamp" appear to be a deliberate attempt by Apple to cover for their OS's deficiencies.

    -l

  52. Re:This makes me wonder... ?? by karearea · · Score: 1

    sigh

  53. Re:Ignite the flames of the microkernel debate aga by snowdon · · Score: 1

    Except that the same microkernel also runs on x86, alpha, Itanium, blackfin, mips, powerpc (lots of variants), etc.

  54. what it really means by r00t · · Score: 1

    Whenever a microkernel system (either a HURD-like real one or a layered hack) beats a standard monolithic kernel, you have proof that either:

    a. the microkernel system is cutting corners

    b. the monolithic kernel needs work

    The old standard of 10 or 15 years ago was microkernel systems like Mach beating crufty old System V junk. Then along comes Linux and toasts them both. Well, maybe a new optimization has been discovered. If it doesn't involve cutting corners (cheating), it'll be adopted by the monolithic kernels.

  55. Re:RTFA - Wombat is slightly slower, not much fast by tinkertim · · Score: 1

    >>
    That's still really pretty good, given the reputation for slowness than microkernels have. If they can port those optimizations to Linux, then maybe Linux would be even faster.
    >>

    That's kind of happening in (and around) the Xen community, but mostly on the Debian / Xen side of the street. Lots of people have been playing with msxen/ocxen on SBC's (ULV Celeron / P4's) and have optimized the kernel and even some core utils for small memory systems.

    Now you have a whole rash of 'unofficial' Debian packages floating around containing everyone's tinkering. I mention Xen because many of the folks pushing things to be smaller and go faster are doing so based on experience with various microkernels.

    Since clusters + virtualization are a good match, you'll see even more talent taking a closer look at things like Open SSI. The real need now (imho) is to get more corporations with some more bucks paying people to tinker and start adopting with the idea that they'll put the improvements back out to the communities. If more people could feed themselves putting ideas they've had the last 20 months into play, I think you'd really begin to see smart (smaller) thinking applied to the next few kernels, plus some revisiting of others.