Re: [Qemu-devel] [PATCH RFC v2 0/4] block/qapi: refactor and optimize the qmp_query_blockstats()

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

On Wed, Dec 21, 2016 at 05:13:39PM +0800, Dou Liyang wrote:
> Hi Stefan,
> 
> At 12/20/2016 05:39 PM, Stefan Hajnoczi wrote:
> > On Tue, Dec 20, 2016 at 12:32:40AM +0800, Fam Zheng wrote:
> > > On Mon, 12/19 15:02, Stefan Hajnoczi wrote:
> > > > On Mon, Dec 19, 2016 at 04:51:22PM +0800, Dou Liyang wrote:
> > > > > These patches aim to refactor the qmp_query_blockstats() and
> > > > > improve the performance by reducing the running time of it.
> > > > > 
> > > > > qmp_query_blockstats() is used to monitor the blockstats, it
> > > > > querys all the graph_bdrv_states or monitor_block_backends.
> > > > > 
> > > > > There are the two jobs:
> > > > > 
> > > > > 1 For the performance:
> > > > > 
> > > > > 1.1 the time it takes(ns) in each time:
> > > > > the disk numbers     | 10    | 500
> > > > > -------------------------------------
> > > > > before these patches | 19429 | 667722
> > > > > after these patches  | 17516 | 557044
> > > > > 
> > > > > 1.2 the I/O performance is degraded(%) during the monitor:
> > > > > 
> > > > > the disk numbers     | 10    | 500
> > > > > -------------------------------------
> > > > > before these patches | 1.3   | 14.2
> > > > > after these patches  | 0.8   | 9.1
> > > > 
> > > > Do you know what is consuming the remaining 9.1%?
> > > > 
> > > > I'm surprised to see such a high performance impact caused by a QMP
> > > > command.
> > > 
> > > If it's "performance is 9.1% worse only during the 557044 ns when the QMP
> > > command is being processed", it's probably becaues the main loop is stalled a
> > > bit, and it's not a big problem. I'd be very surprised if the degradation is
> > > more longer than that.
> > 
> > It would be interesting to compare against virtio-blk dataplane.  That
> > way the QMP command can execute without interfering with disk I/O activity.
> > 
> > qemu-system-x86_64 ... \
> >     -object iothread,id=iothread0 \
> >     -drive if=none,id=drive0,file=vm.img,format=raw,aio=native,cache=none \
> >     -device virtio-blk-pci,drive=drive0,iothread=iothread0
> 
> Here is the result in the guest with 500 disks:
> 
> QMP command     | not execute | execute in each 0.5s |
> -------------------------------------------------------
> Average Times/s | 102.34675   | 103.128              |
> 
> the degradation is 0.76%, that can be ignored.
> 
> the dd command:
> dd if=date_1.dat of=date_2.dat conv=fsync oflag=direct bs=1k count=400k

Excellent.  It's good to know that dataplane is a solution to this
problem.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]