Re: [PATCH v2 2/2] monitor: increase amount of data for monitor to read
On 24.11.2020 14:03, Vladimir Sementsov-Ogievskiy wrote:
23.11.2020 18:44, Andrey Shinkevich wrote:
QMP and HMP monitors read one byte at a time from the socket or stdin,
which is very inefficient. With 100+ VMs on the host, this results in
multiple extra system calls and CPU overuse.
This patch increases the amount of read data up to 4096 bytes that fits
the buffer size on the channel level.
A JSON little parser is introduced to throttle QMP commands read from
the buffer so that incoming requests do not overflow the monitor input
queue.
Suggested-by: Denis V. Lunev
Signed-off-by: Andrey Shinkevich
Can't we just increase qmp queue instead? It seems a lot simpler:
With the OOB compatibility disabled, the monitor queues one QMP command
at most. It was made for the backward compatibility as stated in the
comment before pushing a command into the queue. To keep that concept
functional, the monitor should track the end of a single QMP command. It
allows the dispatcher handling the command and send a response to client
in time.
With the patch below, the monitor queue will be filled with QMP commands
as many as they will be found in the input buffer. The first command
execution {"execute":"qmp_capabilities"} takes more time and queue will
be filled at full. Then the dispatcher starts execution of other
commands in the monitor queue. The process becomes synchronious. In this
case, we need neither thread nor the queue.
Andrey
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 348bfad3d5..7e721eee3f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -8,7 +8,7 @@
typedef struct MonitorHMP MonitorHMP;
typedef struct MonitorOptions MonitorOptions;
-#define QMP_REQ_QUEUE_LEN_MAX 8
+#define QMP_REQ_QUEUE_LEN_MAX 4096
extern QemuOptsList qemu_mon_opts;
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 84222cd130..1588f00306 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -566,7 +566,7 @@ int monitor_can_read(void *opaque)
{
Monitor *mon = opaque;
- return !qatomic_mb_read(>suspend_cnt);
+ return !qatomic_mb_read(>suspend_cnt) ? 4096 : 0;
}
- with this patch tests pass and performance is even better.
Re: [PATCH v2 2/2] monitor: increase amount of data for monitor to read
24.11.2020 14:03, Vladimir Sementsov-Ogievskiy wrote:
23.11.2020 18:44, Andrey Shinkevich wrote:
QMP and HMP monitors read one byte at a time from the socket or stdin,
which is very inefficient. With 100+ VMs on the host, this results in
multiple extra system calls and CPU overuse.
This patch increases the amount of read data up to 4096 bytes that fits
the buffer size on the channel level.
A JSON little parser is introduced to throttle QMP commands read from
the buffer so that incoming requests do not overflow the monitor input
queue.
Suggested-by: Denis V. Lunev
Signed-off-by: Andrey Shinkevich
Can't we just increase qmp queue instead? It seems a lot simpler:
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 348bfad3d5..7e721eee3f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -8,7 +8,7 @@
typedef struct MonitorHMP MonitorHMP;
typedef struct MonitorOptions MonitorOptions;
-#define QMP_REQ_QUEUE_LEN_MAX 8
+#define QMP_REQ_QUEUE_LEN_MAX 4096
extern QemuOptsList qemu_mon_opts;
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 84222cd130..1588f00306 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -566,7 +566,7 @@ int monitor_can_read(void *opaque)
{
Monitor *mon = opaque;
- return !qatomic_mb_read(>suspend_cnt);
+ return !qatomic_mb_read(>suspend_cnt) ? 4096 : 0;
}
- with this patch tests pass and performance is even better.
Suddenly I found, that this patch ^^ was sent a year ago:
https://patchew.org/QEMU/20190610105906.28524-1-dplotni...@virtuozzo.com/
some questions were asked, so I think we should start from it.
--
Best regards,
Vladimir
Re: [PATCH v2 2/2] monitor: increase amount of data for monitor to read
23.11.2020 18:44, Andrey Shinkevich wrote:
QMP and HMP monitors read one byte at a time from the socket or stdin,
which is very inefficient. With 100+ VMs on the host, this results in
multiple extra system calls and CPU overuse.
This patch increases the amount of read data up to 4096 bytes that fits
the buffer size on the channel level.
A JSON little parser is introduced to throttle QMP commands read from
the buffer so that incoming requests do not overflow the monitor input
queue.
Suggested-by: Denis V. Lunev
Signed-off-by: Andrey Shinkevich
Can't we just increase qmp queue instead? It seems a lot simpler:
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 348bfad3d5..7e721eee3f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -8,7 +8,7 @@
typedef struct MonitorHMP MonitorHMP;
typedef struct MonitorOptions MonitorOptions;
-#define QMP_REQ_QUEUE_LEN_MAX 8
+#define QMP_REQ_QUEUE_LEN_MAX 4096
extern QemuOptsList qemu_mon_opts;
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 84222cd130..1588f00306 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -566,7 +566,7 @@ int monitor_can_read(void *opaque)
{
Monitor *mon = opaque;
-return !qatomic_mb_read(>suspend_cnt);
+return !qatomic_mb_read(>suspend_cnt) ? 4096 : 0;
}
- with this patch tests pass and performance is even better.
--
Best regards,
Vladimir
