search for: max_in_flight

...readed-reads-and-writes.c +++ b/examples/threaded-reads-and-writes.c @@ -41,20 +41,16 @@ static int64_t exportsize; /* Number of commands that can be "in flight" at the same time on each * connection. (Therefore the total number of requests in flight may - * be up to NR_MULTI_CONN * MAX_IN_FLIGHT). qemu's NBD client can - * have up to 16 requests in flight. - * - * Some servers do not support multiple requests in flight and may - * deadlock or even crash if this is larger than 1, but common NBD - * servers should be OK. + * be up to NR_MULTI_CONN * MAX_IN_FLIGHT). See libnbd(3) sectio...

...+; return cmd->handle; } diff --git a/tests/aio-parallel-load.c b/tests/aio-parallel-load.c index 7922acd..a68c714 100644 --- a/tests/aio-parallel-load.c +++ b/tests/aio-parallel-load.c @@ -189,7 +189,6 @@ start_thread (void *arg) size_t i; uint64_t offset, handle; uint64_t handles[MAX_IN_FLIGHT]; - size_t in_flight; /* counts number of requests in flight */ int dir, r, cmd; time_t t; bool expired = false; @@ -231,8 +230,8 @@ start_thread (void *arg) assert (nbd_read_only (nbd) == 0); /* Issue commands. */ - in_flight = 0; - while (!expired || in_flight > 0) {...

v1: https://www.redhat.com/archives/libguestfs/2019-June/msg00014.html I pushed a few bits which are uncontroversial. The main changes since v1 are: An extra patch removes the want_to_send / check for nbd_aio_is_ready in examples/threaded-reads-and-writes.c. This logic was wrong since commit 6af72b87 as was pointed out by Eric in his review. Comments and structure of

...thread pool internally, and if you exceed those limits + * then something will break. + */ +#define NR_MULTI_CONN 8 + +/* Number of commands that can be "in flight" at the same time on each + * connection. (Therefore the total number of requests in flight may + * be up to NR_MULTI_CONN * MAX_IN_FLIGHT). qemu's NBD client can + * have up to 16 requests in flight. + * + * Some servers do not support multiple requests in flight and may + * deadlock or even crash if this is larger than 1, but common NBD + * servers should be OK. + */ +#define MAX_IN_FLIGHT 16 + +/* Number of commands we issue (...

...thread pool internally, and if you exceed those limits + * then something will break. + */ +#define NR_MULTI_CONN 8 + +/* Number of commands that can be "in flight" at the same time on each + * connection. (Therefore the total number of requests in flight may + * be up to NR_MULTI_CONN * MAX_IN_FLIGHT). See libnbd(3) section + * "Issuing multiple in-flight requests". + */ +#define MAX_IN_FLIGHT 64 + +/* The size of reads and writes. */ +#define BUFFER_SIZE (1024*1024) + +/* Number of commands we issue (per thread). */ +#define NR_CYCLES 1000000 + +/* Reader thread. */ +struct thread_s...

I'm not sure if this is worth pursuing. On paper, it makes sense (if we know we have multiple commands batched to send over the wire, AND those commands are short in length, we might as well use MSG_MORE), but the measurement numbers with it applied might just be in the noise. Eric Blake (2): examples: Enhance access patterns of threaded-reads-and-writes states: Another use for MSG_MORE

This works, but there's no time saving and I'm still investigating whether it does what I think it does. Nevertheless I thought I would post it because it (probably) implements the idea I had last night outlined in: https://www.redhat.com/archives/libguestfs/2019-June/msg00010.html The meat of the change is patch 4. Patch 5 is an example which I would probably fold into patch 4 for

I still need to wire in the use of *_notify functions into nbdkit to prove whether it makes the code any faster or easier to maintain, but at least the added example shows one good use case for the new API. Eric Blake (6): api: Add nbd_aio_in_flight generator: Allow DEAD state actions to run generator: Allow Int64 in callbacks states: Prepare for aio notify callback api: Add new

This series introduces a generic readahead interface for btrfs trees. The intention is to use it to speed up scrub in a first run, but balance is another hot candidate. In general, every tree walk could be accompanied by a readahead. Deletion of large files comes to mind, where the fetching of the csums takes most of the time. Also the initial build-ups of free-space-caches and

This series introduces a generic readahead interface for btrfs trees. The intention is to use it to speed up scrub in a first run, but balance is another hot candidate. In general, every tree walk could be accompanied by a readahead. Deletion of large files comes to mind, where the fetching of the csums takes most of the time. Also the initial build-ups of free-space-caches and