[Gllug] performance of xen dom0 vs native linux

[James Courtier-Dutton]

2009/5/8 Nahuel Marisi <nahuelmarisi at gmail.com>:
>
>
> 2009/5/8 Richard Jones <rich at annexia.org>
>>
>> On Fri, May 08, 2009 at 10:41:42AM +0100, Nahuel Marisi wrote:
>> > Hi there,
>> > I'm currently using xen for various experiments (as it's much easier and
>> > cheaper than running two or three linux boxes).
>> > As I tend to use Xen frequently I usually boot directly into it even
>> > when I
>> > don't actually fire up any VMs.
>>
>> Please ignore the other reply by "Juergen Schinker" - it's uninformed
>> nonsense.
>>
>> > I was wondering what's the difference in performance between linux
>> > running
>> > in dom0 and no VMs (domUs) running compared to native linux.
>>
>> There's a small performance difference.  Dom0 under Linux will be a
>> few percentage points slower.  You'll not be likely to notice it
>> unless you're doing some very particular things.
>>
>> > Obviously if you use something like virtualbox when there are no VMs
>> > running
>> > you just have linux running natively so you have no performance
>> > penalties.
>> > Is it the same if you're running Xen with no hosts?
>>
>> No ...  You always have the small penalty of the hypervisor.
>>
>> > Does it affect the way linux runs in any way?
>>
>> Yes.  Dom0 is a 'special' guest.  It's a guest running a
>> paravirtualized kernel.  But it also has direct access to most
>> hardware, which other (DomU) guests won't have.
>>
>> One implication of this are that there is slightly less physical RAM
>> available.  Also any resource which is intermediated by the hypervisor
>> -- memory, CPU flags, interrupts -- can be problematic because you're
>> relying on the Xen hypervisor to support your hardware fully in each
>> of these areas.
>>
>> A more serious problem is with features like powersaving and suspend.
>> The hypervisor doesn't know how to powersave or suspend, and the dom0
>> can't make the right decisions because it doesn't know what's
>> happening in the other domains.  This can make Xen less than useful on
>> laptops.
>>
>> Then there is the general mess of Xen network scripts.
>>
>> This is of course why it's better to use Linux _as_ the hypervisor.
>> Hence KVM ...
>>
>> Rich.
>
> Thanks for the detailed reply Rich.
> I haven't actually played around with KVM yet (it's next on the list).
> However, isn't KVM slower than Xen since it has to emulate
> most of the hardware (ie, hardrive controller, graphics card, etc) through
> the use of qemu? As oppose to Xen which has direct access to it, and uses
> dom0 kernel modules?
>
> Unfortunately it is running on a laptop and I actually have experience
> problems with fans running more than usual (although it's hard to say if
> it's Xen's fault).
> If it uses the dom0's kernel modules can't it Xen (who is aware of all
> virtual guests) make good decisions about power saving?
>
> Also KVM requires hardware virtualization. Isn't that slower than
> paravirtualization ?
>

There is a lot of choice out there. xen, kvm, qemu, qemu with kqemu.
qemu with kvm, virtual box, dosemu, dosbox, the list goes on.
They each have different benefits.
Some of them use more so called "hardware acceleration" such as Intel
VT or AMD-V.
It has been shown that using hardware acceleration can actually slow
some applications down when compared with software emulation,
particularly with the intel vt and amd-v hardware instructions.
Example applications are ones that use a lot of malloc/free calls.
intel-vt and amd-v can slow these applications down quite a lot.

All modern x86 processors support a vm86 mode. This mode executes a
majority of the applications instructions natively even before intel
vt and amd-v instructions came along.
dosemu uses this vm86 mode which is why dosemu runs applications fast.
I think you are using the correct approach, trying many different
options and see which best suit your application. Your laptop might
not support the Intel VT and AMD-V.
Para-virtualisation uses a good approach by instead of having to
emulate actual devices, it provides a special device driver for the
guest that improves performance when talking to devices. Emulating
actual devices leads to performance issues due to the double buffering
etc. required. Para-virtualisation can help considerably for
applications that use a lot of device io.
The very latest CPUs are introducing iommu's that allow the guest OS
to talk directly to the hardware. This could improve performance still
further, but would prevent two guest OS's sharing a single hardware
device.

I have an older laptop, that does not have Intel-vt and amd-v support,
and I do not have any specific applications needed to be optimized so
I just use qemu with kqemu. This lets qemu use VM86 mode, so it is
fast.
If I had a laptop with intel-vt and amd-v support, I would probably
use qemu with kvm.

Kind Regards

James
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug