|
From: | zhenwei pi |
Subject: | Re: [Qemu-devel] [External Email] Re: [PATCH 3/3] qapi: add block size histogram interface |
Date: | Fri, 21 Jun 2019 09:52:15 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
On 6/20/19 10:03 PM, Eric Blake wrote:
On 6/20/19 3:54 AM, zhenwei pi wrote:Set/Clear block size histograms through new command x-block-size-histogram-set and show new statistics in query-blockstats results.I'm guessing this is modeled after the existing block-latency-histogram-set command?
zhenwei: Yes, it is.
Signed-off-by: zhenwei pi <address@hidden> --- block/qapi.c | 24 ++++++++++++ blockdev.c | 56 +++++++++++++++++++++++++++ qapi/block-core.json | 105 ++++++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 184 insertions(+), 1 deletion(-) +++ b/qapi/block-core.json @@ -633,6 +633,100 @@ '*boundaries-flush': ['uint64'] } }##+# @BlockSizeHistogramInfo: +# +# Block size histogram. +# +# @boundaries: list of interval boundary values in nanoseconds, all greater +# than zero and in ascending order. +# For example, the list [8193, 32769, 131073] produces the +# following histogram intervals: +# [0, 8193), [8193, 32769), [32769, 131073), [131073, +inf). +# +# @bins: list of io request counts corresponding to histogram intervals. +# len(@bins) = len(@boundaries) + 1 +# For the example above, @bins may be something like [6, 3, 7, 9], +# and corresponding histogram looks like: +# +# Since: 4.0You've missed 4.0; the next release is 4.1.
zhenwei: OK, I will fix all the version info.
+## +{ 'struct': 'BlockSizeHistogramInfo', + 'data': {'boundaries': ['uint64'], 'bins': ['uint64'] } }This is identical to struct BlockLatencyHistogramInfo; can we instead rename the type (which does not affect API) and share it between both implementations, instead of duplicating it?
zhenwei: Good idea. But I am confused about the compatibility of the structure BlockLatencyHistogramInfo. If I rename BlockLatencyHistogramInfo to BlockHistogramInfo, it will be common.
+ +## +# @x-block-size-histogram-set:Does this need to be experimental from the get-go? Or can it be stable by dropping 'x-' since it matches the fact that block-latency-histogram-set is stable?
zhenwei: OK, I will drop 'x-' prefix.
+# +# Manage read, write and flush size histograms for the device. +# +# If only @id parameter is specified, remove all present size histograms +# for the device. Otherwise, add/reset some of (or all) size histograms. +# +# @id: The name or QOM path of the guest device. +# +# @boundaries: list of interval boundary values (see description in +# BlockSizeHistogramInfo definition). If specified, all +# size histograms are removed, and empty ones created for all +# io types with intervals corresponding to @boundaries (except for +# io types, for which specific boundaries are set through the +# following parameters). +# +# @boundaries-read: list of interval boundary values for read size +# histogram. If specified, old read size histogram is +# removed, and empty one created with intervals +# corresponding to @boundaries-read. The parameter has higher +# priority then @boundaries. +# +# @boundaries-write: list of interval boundary values for write size +# histogram. +# +# @boundaries-flush: list of interval boundary values for flush size +# histogram. +# +# Returns: error if device is not found or any boundary arrays are invalid. +# +# Since: 4.04.1+# +# Example: set new histograms for all io types with intervals +# [0, 8193), [8193, 32769), [32769, 131073), [131073, +inf): +# +# -> { "execute": "x-block-size-histogram-set", +# "arguments": { "id": "drive0", +# "boundaries": [8193, 32769, 131073] } } +# <- { "return": {} } +# +# Example: set new histogram only for write, other histograms will remain +# not changed (or not created): +# +# -> { "execute": "x-block-size-histogram-set", +# "arguments": { "id": "drive0", +# "boundaries-write": [8193, 32769, 131073] } } +# <- { "return": {} } +# +# Example: set new histograms with the following intervals: +# read, flush: [0, 8193), [8193, 32769), [32769, 131073), [131073, +inf) +# write: [0, 4097), [4097, 8193), [8193, 32769), [32769, +inf) +# +# -> { "execute": "x-block-size-histogram-set", +# "arguments": { "id": "drive0", +# "boundaries": [8193, 32769, 131073], +# "boundaries-write": [4097, 8193, 32769] } } +# <- { "return": {} } +# +# Example: remove all size histograms: +# +# -> { "execute": "x-block-size-histogram-set", +# "arguments": { "id": "drive0" } } +# <- { "return": {} } +## +{ 'command': 'x-block-size-histogram-set', + 'data': {'id': 'str', + '*boundaries': ['uint64'], + '*boundaries-read': ['uint64'], + '*boundaries-write': ['uint64'], + '*boundaries-flush': ['uint64'] } }Again, this copies heavily from block-latency-histogram-set. But changing the command name is not API compatible. Should we have a single new command 'block-histogram-set' which takes an enum choosing between 'latency' and 'size', and start the deprecation clock on 'block-latency-histogram-set'? (and defaulting to 'latency' for back-compat
zhenwei: this actually copies from block-latency-histogram-set, because the two APIs have the similar logic but different structure BlockLatencyHistogramInfo and BlockSizeHistogramInfo. For further extension, a single new command 'block-histogram-set' with enum operation is better. So, should I remove 'block-latency-histogram-set' and add 'block-histogram-set'?
+ + +## # @BlockInfo: # # Block device information. This structure describes a virtual device and @@ -918,6 +1012,12 @@ # # @flush_latency_histogram: @BlockLatencyHistogramInfo. (Since 4.0) # +# @x_rd_size_histogram: @BlockSizeHistogramInfo. (Since 4.0) +# +# @x_wr_size_histogram: @BlockSizeHistogramInfo. (Since 4.0) +# +# @x_flush_size_histogram: @BlockSizeHistogramInfo. (Since 4.0)since 4.1 on all of these additions.+# # Since: 0.14.0 ## { 'struct': 'BlockDeviceStats', @@ -933,7 +1033,10 @@ 'timed_stats': ['BlockDeviceTimedStats'], '*rd_latency_histogram': 'BlockLatencyHistogramInfo', '*wr_latency_histogram': 'BlockLatencyHistogramInfo', - '*flush_latency_histogram': 'BlockLatencyHistogramInfo' } } + '*flush_latency_histogram': 'BlockLatencyHistogramInfo', + '*x_rd_size_histogram': 'BlockSizeHistogramInfo', + '*x_wr_size_histogram': 'BlockSizeHistogramInfo', + '*x_flush_size_histogram': 'BlockSizeHistogramInfo' } }### @BlockStats:
-- Thanks and Best Regards, zhenwei pi
[Prev in Thread] | Current Thread | [Next in Thread] |