[Top][All Lists]

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

Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2

From: Alexander Graf
Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
Date: Wed, 4 Aug 2010 18:51:33 +0200

On 04.08.2010, at 18:49, Anthony Liguori wrote:

> On 08/04/2010 11:48 AM, Alexander Graf wrote:
>> On 04.08.2010, at 18:46, Anthony Liguori wrote:
>>> On 08/04/2010 11:44 AM, Avi Kivity wrote:
>>>> On 08/04/2010 03:53 PM, Anthony Liguori wrote:
>>>>> So how do we enable support for more than 20 disks?  I think a 
>>>>> virtio-scsi is inevitable..
>>>> Not only for large numbers of disks, also for JBOD performance.  If you 
>>>> have one queue per disk you'll have low queue depths and high interrupt 
>>>> rates.  Aggregating many spindles into a single queue is important for 
>>>> reducing overhead.
>>> Right, the only question is, to you inject your own bus or do you just 
>>> reuse SCSI.  On the surface, it seems like reusing SCSI has a significant 
>>> number of advantages.  For instance, without changing the guest's drivers, 
>>> we can implement PV cdroms or PC tape drivers.
>> What exactly would keep us from doing that with virtio-blk? I thought that 
>> supports scsi commands already.
> I think the toughest change would be making it appear as a scsi device within 
> the guest.  You could do that to virtio-blk but it would be a flag day as 
> reasonable configured guests will break.
> Having virtio-blk device show up as /dev/vdX was a big mistake.  It's been 
> nothing but a giant PITA.  There is an amazing amount of software that only 
> looks at /dev/sd* and /dev/hd*.

I completely agree and yes, we should move in that direction IMHO. I don't see 
why virtio-blk should be any different from megasas for example.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]