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

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 '' \ >

Previously we measured the total time and used it to calculate the rate of different operations. This is incorrect and hides the real throughput. A more useful way is to measure the time we spent in each operation. Here is an example run with this change: $ ./nbdkit --foreground \ --unix /tmp/nbd.sock \ --exportname '' \ --filter stats \ file file=/var/tmp/dst.img \

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 '' \ --filter stats \ file file=/var/tmp/dst.img \ statsfile=/dev/stderr \ --run 'qemu-img convert

Since v1: - rework .can_cache to be tri-state, with default of no advertisement (ripple effect through other patches) - add a lot more patches in order to round out filter support And in the meantime, Rich pushed NBD_CMD_CACHE support into libnbd, so in theory we now have a way to test cache commands through the entire stack. Eric Blake (24): server: Internal hooks for implementing

On Sat, Nov 30, 2019 at 02:17:06AM +0200, Nir Soffer wrote: > Previously we measured the total time and used it to calculate the rate > of different operations. This is incorrect and hides the real > throughput. A more useful way is to measure the time we spent in each > operation. > > Here is an example run with this change: > > $ ./nbdkit --foreground \ > --unix

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

Commit 975dab14 argued that for simple lock/unlock sequences, it was easier to avoid the cleanup.h macros. But since that time, we added additional sanity checking to the macros, at which point the boilerplate of inlining that sanity checking is outweighed compared to just using the macros in more places. Signed-off-by: Eric Blake <eblake@redhat.com> --- filters/cache/cache.c | 23

Hi all -- first time poster, hoping that this is going to the right list. Also a complete LLVM newbie, so please correct any glaring errors in my understanding. I am an architecture researcher at Penn State working on Processing in Memory (PIM) architectures. Currently, I plan to use LLVM to detect and replace groups of instructions which can be accelerated in memory. Once a group of

On Sat, Nov 30, 2019 at 9:13 AM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Sat, Nov 30, 2019 at 02:17:06AM +0200, Nir Soffer wrote: > > Previously we measured the total time and used it to calculate the rate > > of different operations. This is incorrect and hides the real > > throughput. A more useful way is to measure the time we spent in each > >

ASM is the text output you want printed in a textual listing of the assembly. The curly braces you see in some text strings like "adcx{l}\t{$src, $dst|$dst, $src}" are there to provide different operand orders for at&t syntax vs intel syntax. Anything after $ matches the name in the outs/in part of the instruction. IIC_SSE_PREFETCH is part of the scheduler system to provide

Craig, thanks for the quick response. That helps a lot. I had no clue they were buried in there, though I guess I should have looked harder -- the hex should have given me a clue, perhaps! For the sake of my own edification (and not taking up too much of your time) I will try to generate it myself. I've found the definition of the "I" class at line 358 of

Great info -- all of this has been incredibly useful. Do you have any links to the documentation from this, or does it just come from your experiential knowledge? FYI, I achieved what I set out to achieve when I wrote this email. I'm moving on to a more complex goal now, but the original question was answered completely, in my opinion. This was the key line: def CACHEOP : I<0x06, RawFrm,