On 23.11.2020 18:44, Andrey Shinkevich wrote:
The subject was discussed here:
https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00206.html

This series is a solution for the issue with QMP monitor buffered input.
A JSON little parser is introduced to separate QMP commands read from the
input buffer so that incoming requests do not overwhelm the monitor queue.
A side effect raised in the test #247 was managed in the first patch.
It may be considered as a workaround. Any sane fix suggested will be
appreciated.

Note:
This series goes after the Vladimir's one:
'[PATCH v3 00/25] backup performance: block_status + async"'
To make the test #129 passed, the following patch should be applied first:
'[PATCH v3 01/25] iotests: 129 don't check backup "busy"'.

v2:
   02: The static JSONthrottle object was made a member of the Chardev 
structure.
       The fd_chr_read functions were merged.
       The monitor thread synchronization was added to protect the input queue
       from overflow.

Andrey Shinkevich (2):
   iotests: add another bash sleep command to 247
   monitor: increase amount of data for monitor to read

  chardev/char-fd.c          | 35 +++++++++++++++++++++++++++++++++--
  chardev/char-socket.c      | 42 +++++++++++++++++++++++++++++++++++++++---
  chardev/char.c             | 41 +++++++++++++++++++++++++++++++++++++++++
  include/chardev/char.h     | 15 +++++++++++++++
  monitor/monitor.c          |  2 +-
  tests/qemu-iotests/247     |  2 ++
  tests/qemu-iotests/247.out |  1 +
  7 files changed, 132 insertions(+), 6 deletions(-)



The Vladimir's modified test case

$ time (echo "{ 'execute': 'qmp_capabilities' }"; for i in {1..10000}; do echo "{ 'execute': 'query-block-jobs' } {"execute":"query-status"} { 'execute': 'query-block-jobs' } {"execute":"query-status"}"; done; echo "{ 'execute': 'quit' }" ) | ./build/qemu-system-x86_64 -qmp stdio > /dev/null

shows the following performance

on master:
real    0m5.188s
user    0m5.310s
sys     0m2.539s

after the patch applied:
real    0m2.227s
user    0m2.483s
sys     0m0.480s

Andrey

Reply via email to