[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |