Re: [Xen-devel] design philosophy of blktap

[Felipe Franciosi <felipe.franciosi@xxxxxxxxxx>]

> -----Original Message-----
> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of George
> Dunlap
> Sent: 20 July 2015 10:53
> To: Xuehan Xu; Felipe Franciosi
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] design philosophy of blktap
> 
> On Mon, Jul 20, 2015 at 6:01 AM, Xuehan Xu <xxhdx1985126@xxxxxxxxx>
> wrote:
> > Hi, everyone.
> >
> > I don't quite follow the design philosophy of blktap. Since every
> > virtual disk is backed by a tapdisk process, when there are hundreds
> > of domU running and doing I/O operation simultaneously, which means
> > that hundreds of tapdisk process are doing I/O read/write
> > simulataneously in dom0, won't the I/O performance of domU be hurt badly?
> 
> I think Felipe (cc'd) might be the best person to answer this sort of 
> question.
> 
>  -George

(I apologise for the delay in responding to this. I was away on holidays!)

Hi Xuehan,

I believe you are considering the case where the dom0 CPU capacity is exhausted 
because there are too many tapdisks working. This is a common situation which 
is not limited to the blktap approach; the performance of anything that a guest 
does which requires dom0 time will be subjected to dom0's capacity (e.g. device 
emulation via qemu, network traffic via netback).

The plain and simple solution is to give dom0 more CPU power (i.e. more vCPUs, 
perhaps as many as available pCPUs, but bear in mind that some Linux kernels 
might not perform well with a large amount of CPUs). As a matter of fact, 
tapdisk3 is known to scale better than any other alternative for virtualised 
storage on Xen when it comes to aggregate guest performance.

You can find out more about it on my XPDS14 talk on this topic:
http://www.xenproject.org/component/allvideoshare/video/xpds14-scaling.html

Cheers,
Felipe
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel