[Top][All Lists]

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

Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/2] block latency histogram

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/2] block latency histogram
Date: Thu, 8 Mar 2018 22:07:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

08.03.2018 21:56, Emilio G. Cota wrote:
On Thu, Mar 08, 2018 at 14:42:29 +0300, Vladimir Sementsov-Ogievskiy wrote:
Hi Emilio!

Looked through qdist, if I understand correctly, it saves each added (with
different value) element. It is not effective for disk io timing - we'll
have too much elements. In my approach, histogram don't grow, it initially
have several ranges and counts hits to each range.
I thought about this use case, i.e. having a gazillion elements.
You should just do some pre-binning before inserting samples
into qdist, as pointed out in this comment in qdist.h:

  * Samples with the same 'x value' end up in the same qdist_entry,
  * e.g. inc(0.1) and inc(0.1) end up as {x=0.1, count=2}.
  * Binning happens only at print time, so that we retain the flexibility to
  * choose the binning. This might not be ideal for workloads that do not care
  * much about precision and insert many samples all with different x values;
  * in that case, pre-binning (e.g. entering both 0.115 and 0.097 as 0.1)
  * should be considered.
struct qdist_entry {
     double x;
     unsigned long count;

Let me know if you need help with that.



In this case, I'll have to do same bin search (and store same interval settings) as I already do, on my part, to calculate a parameter for qdist interface. And I'll have store almost all same data on my part. So, it doesn't really help. And I need nothing of qdist benefits: I don't need (and don't want) dynamic allocation of bins on adding an element or any type of visualization.

Best regards,

reply via email to

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