[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Subject: RE: [Xen-users] Poor disk io performance in domUs



 

> -----Original Message-----
> From: David Brown [mailto:dmlb2000@xxxxxxxxx] 
> Sent: 22 June 2007 17:00
> To: Petersson, Mats
> Cc: Andrej Radonic; xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Subject: RE: [Xen-users] Poor disk io 
> performance in domUs
> 
> > Actually, if you expect IOMMU to solve the problem, you can 
> do the same
> > (with slightly less security, admittedly) in Para-virtual 
> domains today
> > - since IOMMU can only translate and protect on a 
> per-device level, so
> > you need to have one device per domain.
> 
> Well yeah the same thing can be accomplished today but there's that
> little kernel process that has to do the mapping in software and that
> takes away cpu time from doing other work.

Assuming we're talking about Para-virtual domains, the guest already
knows the physical address, so there's no need to do any extra work
here. [this assumes the packet of data doesn't have to be copied into a
contiguous buffer, that's a differrent matter - but it's quite likely
that it doesn't actually have to be - particularly not for small packets
of data such as network traffic]. 

> 
> Ideally, you would bring up a box with say 6+ domains on it plus a
> dom0 and no matter what you did with the domains it wouldn't adversely
> affect the other domains, even dom0. So this theoretical box would
> probably have 7 network devices (with IOMMU) mapped to the various
> domains in hardware so no software has to do the mapping to the
> different address spaces. Similarly with disk devices, there would
> have to be 7 scsi devices so that each could be mapped the the various
> domains. Then there would be only one box and it could really look
> like 7 different machines and have the same performance as it would
> normally.

IOMMU on Para-virtual domains isn't going to give you any advantage
other than proper protection. For HVM domains, it's the key that unlocks
guest-access to hardware (and of course giving protection).

> 
> > So if you have a disk-controller with disk for each domain, 
> you could do
> > that today. Same with network controllers [there are even 
> some network
> > controllers which are "multihead", meaning that they 
> present themselves
> > as multiple individual devices, even though it all goes 
> onto a single
> > network connection].
> >
> > The other point that immediately comes to mind here is that the Dom0
> > should definitely have it's own CPU if you're doing a lot of
> > disk/network IO through it.
> 
> Well, I should have said hardware IOMMU, but you're right, its on a
> device based level which doesn't help I/O so much since that's not
> based on disks. Really what we need is a scsi based IOMMU controler of
> some kind that can do the translation on the device itself per disk,
> now that'd be cool :)

It's not beyond the realms of possibility that future disk controllers
will have "multi-head" capabilities too - so that you could have a
single SCSI-card in the machine and 4 disks, but to the software, it
would appear like 4 SCSI controllers with one disk each. 

Note this is PURE speculation - I have no idea if anyone is working on
something like that. I only know of network cards like that. But froma
conceptual standpoint, there's no real problem doing that. 

--
Mats
> 
> - David Brown
> 
> 
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.