Am 27.02.2017 um 22:09 schrieb Eric Blake:
On 02/27/2017 05:03 AM, Peter Lieven wrote:
the convert process is currently completely implemented with sync operations.
That means it reads one buffer and then writes it. No parallelism and each sync
request takes as long as it takes until it is completed.
This patches introduces 2 new cmdline parameters. The -m parameter to specify
the number of coroutines running in parallel (defaults to 8). And the -W
paremeter to
s/paremeter/parameter/
allow qemu-img to write to the target out of order rather than sequential. This
improves
performance as the writes do not have to wait for each other to complete.
Signed-off-by: Peter Lieven <[email protected]>
---
@@ -1798,7 +1908,7 @@ static int img_convert(int argc, char **argv)
{"image-opts", no_argument, 0, OPTION_IMAGE_OPTS},
{0, 0, 0, 0}
};
- c = getopt_long(argc, argv, "hf:O:B:ce6o:s:l:S:pt:T:qn",
+ c = getopt_long(argc, argv, "hf:O:B:ce6o:s:l:S:pt:T:qnm:W",
long_options, NULL);
if (c == -1) {
break;
@@ -1890,6 +2000,18 @@ static int img_convert(int argc, char **argv)
case 'n':
skip_create = 1;
break;
+ case 'm':
+ num_coroutines = atoi(optarg);
atoi() should be avoided. It has no error checking, so it treats '-m 1'
and '-m 1k' identically. You are a bit justified in that '-m junk' gets
treated like '-m 0' and rejected, but it's still a poor error message in
that case.
would you use qemu_strtoul or parse_uint instead?
Kevin, shall I send a V3?
Peter
