similar to: [PATCH nbdkit v3 0/5] filters: stats: More useful, more friendly

- Use more friendly output with GiB and MiB/s - Measure time per operation, providing finer grain stats - Add total stats for understanding system throughput - Add missing stats for flush I hope that these changes will help to understand and improve virt-v2v performance. Changes since v1: - Keep bytes values - Increase precision to 0.001 GiB and 0.001 MiB/s - Add total stats - Show time before

Change the first line to show total ops, time, total size, and rate. The totals are useful for understanding the total throughput of the application. --- filters/stats/nbdkit-stats-filter.pod | 8 ++++---- filters/stats/stats.c | 19 ++++++++++++++++++- 2 files changed, 22 insertions(+), 5 deletions(-) diff --git a/filters/stats/nbdkit-stats-filter.pod

Previously we measured the total time and used it to calculate the rate of different operations. This is misleading and hiding the real throughput. Change single operation stats to use the time spent in this operation. To understand total system throughput, show also new "total" stats, summing ops, bytes of other operations, and using the total time. This works well for copying images

I find bytes and bits-per-second unhelpful and hard to parse. Add also size in GiB, and show rate in MiB per second. This works well for common disk images and storage. Here is an example run with this change: $ ./nbdkit --foreground \ --unix /tmp/nbd.sock \ --exportname '' \ --filter stats \ file file=/var/tmp/dst.img \ statsfile=/dev/stderr \ --run 'qemu-img

Make stats output easier to parse and more useful for humans. Here is an example output with this change: elapsed time: 1.33377 s read: 248 ops, 4.75 MiB, 3.56 MiB/s write: 78 ops, 32.64 MiB, 24.48 MiB/s trim: 33 ops, 1.00 GiB, 767.75 MiB/s flush: 9 ops, 0 bytes, 0 bytes/s --- filters/stats/nbdkit-stats-filter.pod | 11 ++++---- filters/stats/stats.c | 36

- Use more friendly output with GiB and MiB/s. - Measure time per operation, providing finer grain stats - Add missing stats for flush I hope that these changes will help to understand and imporve virt-v2v performance. Nir Soffer (3): filters: stats: Show size in GiB, rate in MiB/s filters: stats: Measure time per operation filters: stats: Add flush stats filters/stats/stats.c | 117

Change-Id: I16bd4cd990d8ad5888c9e30016218ac25242ecb5 --- src/opus_multistream_encoder.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/opus_multistream_encoder.c b/src/opus_multistream_encoder.c index 30cafe1..c07132f 100644 --- a/src/opus_multistream_encoder.c +++ b/src/opus_multistream_encoder.c @@ -747,7 +747,8 @@ static void ambisonics_rate_allocation( if

flush is usually called once but it can take significant time, so we need to include it. Here is an example run with this change: $ ./nbdkit --foreground \ --unix /tmp/nbd.sock \ --exportname '' \ --filter stats \ file file=/var/tmp/dst.img \ statsfile=/dev/stderr \ --run 'qemu-img convert -p -n -f raw -O raw -T none /var/tmp/fedora-30.img

On Sat, Nov 30, 2019 at 02:17:05AM +0200, Nir Soffer wrote: > I find bytes and bits-per-second unhelpful and hard to parse. Using GiB > for sizes works for common disk images, and MiB/s works for common > storage throughput. > > Here is an example run with this change: > > $ ./nbdkit --foreground \ > --unix /tmp/nbd.sock \ > --exportname '' \ >

In no particular order. Some of these need further investigation. ---------------------------------------------------------------------- I had to patch libguestfs not to use febootstrap-supermin-helper --copy-kernel option. See attachment #1. This could be avoided by providing a newer febootstrap in Wheezy. I had to patch libguestfs to make it not use the (not working) virtio-scsi in old

Hi, another issue I''m seeing with 3.0-rc2 and Xen is that there is an unexpectedly high amount of kernel reserved memory. I suspect that Linux allocates page table entries and corresponding data structures for the whole 6GB areas of the provided ''physical RAM map'' even though it has rather big unusable holes in it. [ 0.000000] BIOS-provided physical RAM map: [

> > The rest of the code is screaming out to be refactored so we aren't > > repeating the same change over and over. How about using something > > like the attached patch as an initial refactoring? > > Very nice, do you want to push it? I can include it in v2. Yes I'll push it now. Will think about the rest of your email later! Rich. -- Richard Jones,

On Mon, Jul 10, 2023 at 12:20:01PM +0300, Gavin Li wrote: > Currently, coalescing parameters are grouped for all transmit and receive > virtqueues. This patch series add support to set or get the parameters for > a specified virtqueue. > > When the traffic between virtqueues is unbalanced, for example, one virtqueue > is busy and another virtqueue is idle, then it will be very

On Thu, 13 Jul 2023 07:40:12 -0400, "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Mon, Jul 10, 2023 at 12:20:01PM +0300, Gavin Li wrote: > > Currently, coalescing parameters are grouped for all transmit and receive > > virtqueues. This patch series add support to set or get the parameters for > > a specified virtqueue. > > > > When the

Dear all, When I debugged the execution performance of an application using strace, I found there are some system calls like open and stat64 which run faster on XenLinux than the standard Linux. The following is the output of running "strace -c /bin/sh -c /bin/echo foo" on both systems. An open call runs averagely 109 usec on standard Linux but only 41 usecs on XenLinux. An stat64

Hello, I have found, that ocfs2 is very slow when doing I/O operation without cache. See a simple test: ng-vvv1:~# dd if=/data/verejna/dd-1G bs=1k | dd of=/dev/null 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB) copied, 395.183 s, 2.7 MB/s 2097152+0 records in 2097152+0 records out 1073741824 bytes (1.1 GB) copied, 395.184 s, 2.7 MB/s The underlying block device is quite

Unify virtio_net_ctrl_coal_tx and virtio_net_ctrl_coal_rx structs into a single struct, virtio_net_ctrl_coal, as they are identical. This patch follows the VirtIO spec patch: https://lists.oasis-open.org/archives/virtio-comment/202302/msg00431.html Signed-off-by: Alvaro Karsz <alvaro.karsz at solid-run.com> --- drivers/net/virtio_net.c | 15 +++++++--------

--- common/include/test-tvdiff.c | 75 +++++++++++++++++++++++++++++------- common/include/tvdiff.h | 13 ++++++- 2 files changed, 74 insertions(+), 14 deletions(-) diff --git a/common/include/test-tvdiff.c b/common/include/test-tvdiff.c index 9cbcfc0..abefb2e 100644 --- a/common/include/test-tvdiff.c +++ b/common/include/test-tvdiff.c @@ -36,7 +36,6 @@ #include <stdlib.h> #include

Hi, questions will follow. --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 99f7bd4..13b3fb1 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -40,8 +40,6 @@ #define BIOSLOG(sip, fmt, arg...) NV_DEBUG(sip->dev, fmt, ##arg) #define LOG_OLD_VALUE(x) //x -#define BIOS_USLEEP(n)

I do have a question about whether patch 2 is right, or whether I've exposed a bigger problem in the truncate (and possibly other) filter, but the rest seem fairly straightforward. Eric Blake (4): server: Check for pthread lock failures truncate: Factor out reading real_size under mutex plugins: Check for mutex failures filters: Check for mutex failures filters/cache/cache.c