Re: [Libguestfs] libnbd flamegraph Odd benchmark results

On Sun, May 30, 2021 at 12:13:28AM +0530, Abhay Raj Singh wrote: I think this comes back to something that Nir Soffer said last week about number of requests and request size: https://listman.redhat.com/archives/libguestfs/2021-May/msg00121.html I followed up with a discussion about L3 cache size vs default buffer size: https://listman.redhat.com/archives/libguestfs/2021-May/msg00122.html https://listman.redhat.com/archives/libguestfs/2021-May/msg00123.html In short the default settings for nbdcopy are wrong and more performance could be gained by having better settings. The question (for you!) is how we can choose better settings, and whether we should choose simply better defaults or have dynamic settings. My vision for nbdcopy is that it should work "as well as possible" without end users needing to change the settings on the command line. But there may be cases where users need to or want to tune particular settings. But I'm not sure how to achieve that. eg: Should we choose defaults based on the number of cores and amount of memory detected at run time? Or is that too complicated, and maybe we can choose more conservative defaults? Really I'm looking for your answers here. I do believe that qemu gets this wrong. There are a bunch of command line parameters that you have to set to get good performance, and they're not even documented. I would imagine that the large default buffer size x number of buffers would cause problems no matter the size of the virtual disk. [...] My guess is sampling rate would not affect things very much, but I didn't measure it so I could be wrong. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW