KVM call agenda for Nov 23

KVM call agenda for Nov 23

[Juan Quintela]

Please send in any agenda items you are interested in covering.

thanks, Juan.

[Qemu-devel] KVM call agenda for Nov 23

[Juan Quintela]

Please send in any agenda items you are interested in covering.

thanks, Juan.

Re: KVM call agenda for Nov 23

[Stefan Hajnoczi]

On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela <quintela@redhat.com> wrote:
>
> Please send in any agenda items you are interested in covering.

QCOW2 performance roadmap:
* What can be done to achieve near-raw image format performance?
* Benchmark results from an ideal QCOW2 model.

Stefan

[Qemu-devel] Re: KVM call agenda for Nov 23

[Stefan Hajnoczi]

On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela <quintela@redhat.com> wrote:
>
> Please send in any agenda items you are interested in covering.

QCOW2 performance roadmap:
* What can be done to achieve near-raw image format performance?
* Benchmark results from an ideal QCOW2 model.

Stefan

Re: KVM call agenda for Nov 23

[Kevin Wolf]

Am 22.11.2010 14:55, schrieb Stefan Hajnoczi:
> On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela <quintela@redhat.com> wrote:
>>
>> Please send in any agenda items you are interested in covering.
> 
> QCOW2 performance roadmap:
> * What can be done to achieve near-raw image format performance?
> * Benchmark results from an ideal QCOW2 model.

Some thoughts on qcow2 performance:

== Fully allocated image ==
Should be able to perform similar to raw because there is very little
handling of metadata. Additional I/O only if an L2 table must be read
from the disk.

* Should we increase the L2 table cache size to make it happen less
often? (Currently 16 * 512 MB, QED uses more)

Known problems:
* Synchronous read of L2 tables; should be made async
** General thought on making things async: Coroutines? What happened to
that proposal?
* We may want to have online defragmentation eventually

== Growing stand-alone image ==
Stand-alone images (i.e. images without a backing file) aren't that
interesting because you would use raw for them anyway if you needed
optimal performance. We need to be "good enough" here.

However, all of the problems that arise from dealing with metadata apply
for the really interesting third case, so optimizing them is an
important step on the way.

Known problems:
* Needs a bdrv_flush between refcount table and L2 table write
* Synchronous metadata updates
* Both to be solved by block-queue
** Batches writes and makes the async, can greatly reduce number of
bdrv_flush calls
** Except for cache=writethrough, but this is secondary
** Should we make cache=off the default caching mode in qemu?
writethrough seems to be a bit too much anyway irrespective of the image
format.
* Synchronous refcount table reads
** How frequent are cache misses?
** Making this one async is much harder than L2 table reads. We can make
it a goal for mid-term, but short term we should make it hurt less if
it's a problem in practice.
*** It's probably not, because (without internal snapshots or
compression) we never free clusters, so we fill it sequentially and only
load a new one when the old one is full - and that one we don't even
read, but write, so block-queue will help
* Things like refcount table growth are completely synchronous.
** Not a real problem, because it happens approximately never.

== Growing image with backing file ==
This is the really interesting scenario where you need an image format
that provides some features. For qcow2, it's mostly the same as above.

See stand-alone, plus:
* Needs an bdrv_flush between COW and writing to the L2 table
** qcow2 has already one after refcount table write, so no additional
overhead
* Synchronous COW
** Should be fairly easy to make async

[Qemu-devel] Re: KVM call agenda for Nov 23

[Kevin Wolf]

Am 22.11.2010 14:55, schrieb Stefan Hajnoczi:
> On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela <quintela@redhat.com> wrote:
>>
>> Please send in any agenda items you are interested in covering.
> 
> QCOW2 performance roadmap:
> * What can be done to achieve near-raw image format performance?
> * Benchmark results from an ideal QCOW2 model.

Some thoughts on qcow2 performance:

== Fully allocated image ==
Should be able to perform similar to raw because there is very little
handling of metadata. Additional I/O only if an L2 table must be read
from the disk.

* Should we increase the L2 table cache size to make it happen less
often? (Currently 16 * 512 MB, QED uses more)

Known problems:
* Synchronous read of L2 tables; should be made async
** General thought on making things async: Coroutines? What happened to
that proposal?
* We may want to have online defragmentation eventually

== Growing stand-alone image ==
Stand-alone images (i.e. images without a backing file) aren't that
interesting because you would use raw for them anyway if you needed
optimal performance. We need to be "good enough" here.

However, all of the problems that arise from dealing with metadata apply
for the really interesting third case, so optimizing them is an
important step on the way.

Known problems:
* Needs a bdrv_flush between refcount table and L2 table write
* Synchronous metadata updates
* Both to be solved by block-queue
** Batches writes and makes the async, can greatly reduce number of
bdrv_flush calls
** Except for cache=writethrough, but this is secondary
** Should we make cache=off the default caching mode in qemu?
writethrough seems to be a bit too much anyway irrespective of the image
format.
* Synchronous refcount table reads
** How frequent are cache misses?
** Making this one async is much harder than L2 table reads. We can make
it a goal for mid-term, but short term we should make it hurt less if
it's a problem in practice.
*** It's probably not, because (without internal snapshots or
compression) we never free clusters, so we fill it sequentially and only
load a new one when the old one is full - and that one we don't even
read, but write, so block-queue will help
* Things like refcount table growth are completely synchronous.
** Not a real problem, because it happens approximately never.

== Growing image with backing file ==
This is the really interesting scenario where you need an image format
that provides some features. For qcow2, it's mostly the same as above.

See stand-alone, plus:
* Needs an bdrv_flush between COW and writing to the L2 table
** qcow2 has already one after refcount table write, so no additional
overhead
* Synchronous COW
** Should be fairly easy to make async

Re: KVM call agenda for Nov 23

[Stefan Hajnoczi]

On Tue, Nov 23, 2010 at 2:37 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 22.11.2010 14:55, schrieb Stefan Hajnoczi:
>> On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela <quintela@redhat.com> wrote:
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> QCOW2 performance roadmap:
>> * What can be done to achieve near-raw image format performance?
>> * Benchmark results from an ideal QCOW2 model.

Performance figures from a series of I/O scenarios:
http://wiki.qemu.org/Qcow2/PerformanceRoadmap

Stefan

[Qemu-devel] Re: KVM call agenda for Nov 23

[Stefan Hajnoczi]

On Tue, Nov 23, 2010 at 2:37 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 22.11.2010 14:55, schrieb Stefan Hajnoczi:
>> On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela <quintela@redhat.com> wrote:
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> QCOW2 performance roadmap:
>> * What can be done to achieve near-raw image format performance?
>> * Benchmark results from an ideal QCOW2 model.

Performance figures from a series of I/O scenarios:
http://wiki.qemu.org/Qcow2/PerformanceRoadmap

Stefan

Re: [Qemu-devel] Re: KVM call agenda for Nov 23

[Kevin Wolf]

Am 23.11.2010 15:53, schrieb Stefan Hajnoczi:
> On Tue, Nov 23, 2010 at 2:37 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 22.11.2010 14:55, schrieb Stefan Hajnoczi:
>>> On Mon, Nov 22, 2010 at 1:38 PM, Juan Quintela <quintela@redhat.com> wrote:
>>>>
>>>> Please send in any agenda items you are interested in covering.
>>>
>>> QCOW2 performance roadmap:
>>> * What can be done to achieve near-raw image format performance?
>>> * Benchmark results from an ideal QCOW2 model.
> 
> Performance figures from a series of I/O scenarios:
> http://wiki.qemu.org/Qcow2/PerformanceRoadmap

I added my list to this wiki page now, so that digging them up in the
mailing list archive won't be necessary later.

Kevin

Re: [Qemu-devel] KVM call agenda for Nov 23

[Chris Wright]

* Juan Quintela (quintela@redhat.com) wrote:
> Please send in any agenda items you are interested in covering.

usb-ccid

Re: [Qemu-devel] KVM call agenda for Nov 23

[Chris Wright]

* Juan Quintela (quintela@redhat.com) wrote:
> Please send in any agenda items you are interested in covering.

usb-ccid

Re: [Qemu-devel] KVM call agenda for Nov 23

[Anthony Liguori]

On 11/22/2010 03:45 PM, Chris Wright wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>    
>> Please send in any agenda items you are interested in covering.
>>      
> usb-ccid
>    

aka external device emulation in qemu.

This is an easy topic to discuss in an abstract sense and I'm sure 
everyone has an opinion.  However, what's needed is deep review of the 
current code with an eye towards all of the possible issues we will face 
in the future including live migration, configurability, and 
compatibility.  I need to find some time to spend with the appropriate 
specs.

It would be a lot simpler just to include the emulation in qemu like we 
do for every other device...

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [Qemu-devel] KVM call agenda for Nov 23

[Anthony Liguori]

On 11/22/2010 03:45 PM, Chris Wright wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>    
>> Please send in any agenda items you are interested in covering.
>>      
> usb-ccid
>    

aka external device emulation in qemu.

This is an easy topic to discuss in an abstract sense and I'm sure 
everyone has an opinion.  However, what's needed is deep review of the 
current code with an eye towards all of the possible issues we will face 
in the future including live migration, configurability, and 
compatibility.  I need to find some time to spend with the appropriate 
specs.

It would be a lot simpler just to include the emulation in qemu like we 
do for every other device...

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [Qemu-devel] KVM call agenda for Nov 23

[Anthony Liguori]

On 11/22/2010 03:45 PM, Chris Wright wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>    
>> Please send in any agenda items you are interested in covering.
>>      
> usb-ccid
>    

- vcpu hard limits

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [Qemu-devel] KVM call agenda for Nov 23

[Anthony Liguori]

On 11/22/2010 03:45 PM, Chris Wright wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>    
>> Please send in any agenda items you are interested in covering.
>>      
> usb-ccid
>    

- vcpu hard limits

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [Qemu-devel] KVM call agenda for Nov 23

[Luiz Capitulino]

On Mon, 22 Nov 2010 17:00:41 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 11/22/2010 03:45 PM, Chris Wright wrote:
> > * Juan Quintela (quintela@redhat.com) wrote:
> >    
> >> Please send in any agenda items you are interested in covering.
> >>      
> > usb-ccid
> >    
> 
> - vcpu hard limits

- 0.14 (release date, bug day, -rc planning, etc)

Re: [Qemu-devel] KVM call agenda for Nov 23

[Michael Tokarev]

23.11.2010 15:08, Luiz Capitulino wrote:
[]
> - 0.14 (release date, bug day, -rc planning, etc)

Um, can we have some 0.13.x before, please?.. :)

/mjt

Re: [Qemu-devel] KVM call agenda for Nov 23

[Michael Tokarev]

23.11.2010 15:08, Luiz Capitulino wrote:
[]
> - 0.14 (release date, bug day, -rc planning, etc)

Um, can we have some 0.13.x before, please?.. :)

/mjt

KVM call agenda for Nov 30

[Dor Laor]

Please send in any agenda items you are interested in covering.

thanks, Dor

[Qemu-devel] KVM call agenda for Nov 30

[Dor Laor]

Please send in any agenda items you are interested in covering.

thanks, Dor

Re: KVM call agenda for Nov 30

[Stefan Hajnoczi]

On Tue, Nov 30, 2010 at 12:58 PM, Dor Laor <dlaor@redhat.com> wrote:
> Please send in any agenda items you are interested in covering.

Juan already has a thread for agenda items.  It includes:

"As I forgot to put the call for agenda befor, Anthony already suggested:
- 2011 kvm conference
- 0.14.0 release plan
- infrastructure changes (irc channel migration, git tree migration)"

Stefan

[Qemu-devel] Re: KVM call agenda for Nov 30

[Stefan Hajnoczi]

On Tue, Nov 30, 2010 at 12:58 PM, Dor Laor <dlaor@redhat.com> wrote:
> Please send in any agenda items you are interested in covering.

Juan already has a thread for agenda items.  It includes:

"As I forgot to put the call for agenda befor, Anthony already suggested:
- 2011 kvm conference
- 0.14.0 release plan
- infrastructure changes (irc channel migration, git tree migration)"

Stefan

Re: KVM call agenda for Nov 30

[Avi Kivity]

On 11/30/2010 02:58 PM, Dor Laor wrote:
> Please send in any agenda items you are interested in covering.
>

nested vmx? must pick up pace if want to merge.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: KVM call agenda for Nov 30

[Avi Kivity]

On 11/30/2010 02:58 PM, Dor Laor wrote:
> Please send in any agenda items you are interested in covering.
>

nested vmx? must pick up pace if want to merge.

-- 
error compiling committee.c: too many arguments to function