qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv2 1/6] block: add accounting for merged requests


From: Peter Lieven
Subject: Re: [Qemu-devel] [PATCHv2 1/6] block: add accounting for merged requests
Date: Wed, 22 Oct 2014 22:22:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

Am 22.10.2014 um 20:20 schrieb Eric Blake:
> On 10/22/2014 07:21 AM, Peter Lieven wrote:
>> Signed-off-by: Peter Lieven <address@hidden>
>> Reviewed-by: Max Reitz <address@hidden>
>> ---
>>  block.c                    |    2 ++
>>  block/accounting.c         |    7 +++++++
>>  block/qapi.c               |    2 ++
>>  hmp.c                      |    6 +++++-
>>  include/block/accounting.h |    3 +++
>>  qapi/block-core.json       |    9 ++++++++-
>>  6 files changed, 27 insertions(+), 2 deletions(-)
>>
>> +++ b/qapi/block-core.json
>> @@ -392,13 +392,20 @@
>>  #                     growable sparse files (like qcow2) that are used on 
>> top
>>  #                     of a physical device.
>>  #
>> +# @rd_merged: Reserved (Since 2.2)
> Does this mean it is always output as 0 for now, but may be non-zero at
> some future date if we figure out how to do merged read requests?  Is it
> even worth adding the field if it has no semantics?  We can always add
> it later when it makes sense, and a client can be smart enough to
> realize that a missing field is the same as the field being present with
> value 0 (since that is what clients already have to do for 2.1).
>
> I'd feel better with just a bit more documentation or else omitting the
> field.  The rest of the patch is okay, though.
>

Read merging is no magic. I plan to integrate it for 2.3. There
are a few open questions where and how to implement it, but
this can be solved. The idea was to give people the change to
implement read and write merging statistics at the same time.

But you are right, there should be more comments or the fields
should not be published yet.

Peter




reply via email to

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