Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd like to know what performance impact I could expect running Linux in a virtual machine in Windows. The job I need Linux for is heavy and almost non-stop code compilation with GCC. Dual-boot doesn't look like a very attractive solution, so I'm counting on low VM overhead right now (10-20% would be fine for me, but 50% or more will be unacceptable). Did anyone try to measure the performance difference, are there any comparison tables? What virtual machine with the lowest overhead possible will you suggest?

My host OS is Win7 and I've got a modern Core i7 with VT-x present.


share|improve this question
How much RAM? RAM is super important in VMs – Phoshi May 29 '10 at 11:22
4 Gb so far, but I can easily double it if needed. – vovick May 29 '10 at 11:29
You should at least double it if you use memory intensive task in the guest(s) or want to run more guests. – Shiki May 31 '10 at 16:58
up vote 5 down vote accepted

Caveat: the following is based on my subjective observations, rather than proper objective testing.

Disk I/O for some load patterns are going to be at the top end of your 10-20% bracket, perhaps a little higher, but not near the 50% you state. You can mitigate the I/O hit a number of ways, including:

  • Giving the VM plenty of RAM for the OS to use as cache (this means the host machine having plenty of RAM of course otherwise it will starve and start swapping both itself and the VM)
  • Tell the VM manager not to let any RAM allocated to the VM swap if it can possibly help it
  • Make sure the VM hosts temporary storage in RAM by having /tmp and similar mounted as tmpfs filesystems.
  • Make a good choice of on-disk filesystems and related tweaks in the VM. If all the code and compiler output is held elsewhere too, i.e. in source control and backups, then do away with journalling to reduce writing activity. Also if your filesystem is ext2/3/4 use the noatime option if your build process is fine with this (most, if not all, are) or relatime if noatime is not possible (most distributions now default to relatime, I think).
  • Similarly, if your code and output is safely copied elsewhere, tell your VM manager that it is OK to buffer writes to the VM's vdisks.
  • If you don't feel safe with the riskier options above (possible delayed write caching, no FS journals) you can tweak your build process to use RAM for temporary storage, by making it use that tmpfs mounted /tmp as much as possible.
  • Have the VM's vdisks on a separate drive if you can, that way if it does need to perform a sizeable chunk of I/O operations it won't be competing as much with the host OS and other VMs.
  • Make sure the VM is using fixed-size virtual disks. Growable disks increase the IO performance hit, sometimes considerably.

The I/O hit is going to dwarf any CPU hit somewhat, though there is some performance drop here, too. Unlike I/O though, there is very little you can do about it. With a modern CPU and a virtualisation product that can take advantage of the CPU's explicit virtualisation support the difference for completely CPU bound operations should be no more than a couple of percent. Try to avoid virtual SMP - this can actually be slower than giving the VM a single vCPU because of the way physical CPU time gets scheduled. In VMWare at least a guest with 2 vCPUs must wait until two cores are free in order to get a time-slice from the host scheduler - if the host is under load on top of the VM this can make quite a difference and if the task(s) are mainly CPU bound and can be split appropriately you will often be better off running two or more VMs (assuming you have the RAM to support this) instead of giving one VM multiple vCPUs.

The use pattern you state (constant compile cycles) will be impacted by these performance hits, but I expect you will lose a lot less time this way than you would with the inconvenience of dual-booting. If your Windows use is much less CPU and I/O intensive, i.e. just using office apps and not heavy DB work or gaming or the like, you might want to consider running Linux as the host and Windows in the VM.

share|improve this answer
Thank you so much for your extremely comprehensive answer! I'm really glad to hear that modern virtualisation technologies need so little overhead for cpu-bound activities. It's sad that problems arise when using a virtual machine with several vCPUs, because one can get a great performance gain compiling several files with GCC simultaneously in multiple threads on separate cores. I wonder if there is some way of giving 3 out of 4 cores to a VM solely and putting all other native tasks to the remaining core so that the host scheduler wouldn't affect performance of the VM. – vovick May 29 '10 at 14:54
I forgot a point about fixed/variable allocation vdisks, I've just edited that in. vSMP can give performance gains but host scheduling issues severely limit it in most cases. You might find several smaller VMs running distCC ( more efficient, as backwards as that may sound. Even on a single core though, running concurrent compile operations with make -j <n> or similar can make quite a difference as CPU-intensive and blocking-on-I/O parts of the process generally get interleaved instead of always being queued behind each other. – David Spillett May 31 '10 at 14:00
To set processor affinity of the OS or its specific applications read this Essentially, you'll have to tell everything on the HostOS to run on one processor/core and tell the VM to run on the rest. – Evan Plaice Jul 29 '10 at 11:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .