design philosophy of blktap

design philosophy of blktap

[Xuehan Xu]

[-- Attachment #1.1: Type: text/plain, Size: 350 bytes --]

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?

[-- Attachment #1.2: Type: text/html, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: design philosophy of blktap

[George Dunlap]

On Mon, Jul 20, 2015 at 6:01 AM, Xuehan Xu <xxhdx1985126@gmail.com> 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

Re: design philosophy of blktap

[Felipe Franciosi]

> -----Original Message-----
> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
> Dunlap
> Sent: 20 July 2015 10:53
> To: Xuehan Xu; Felipe Franciosi
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] design philosophy of blktap
> 
> On Mon, Jul 20, 2015 at 6:01 AM, Xuehan Xu <xxhdx1985126@gmail.com>
> 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