mirror of
https://github.com/qemu/qemu.git
synced 2026-07-08 17:56:38 +00:00
9563d0b5e2
Improve adaptive polling by updating each AioHandler's poll.ns
every loop iteration using weighted averages. This reduces CPU
consumption while minimizing performance impact.
Background:
Starting from QEMU 10.0, poll.ns was introduced per event handler
to mitigate excessive fluctuations in IOThread polling times
observed in earlier versions (QEMU 9.x). However, the current
design has limitations:
1. poll.ns is updated only when an event occurs, making it
difficult to treat block_ns as a reliable event interval.
2. The IOThread's next polling time is determined by the maximum
poll.ns among all AioHandlers, meaning idle AioHandlers with
high poll.ns can have an outsized impact on polling duration.
3. For io_uring, idle AioHandlers are cleared after
POLL_IDLE_INTERVAL_NS (7s), but for ppoll/epoll there is no
such mechanism, leading to increased CPU consumption from idle
nodes.
Implementation:
This patch treats block_ns as an event interval and updates each
AioHandler's poll.ns in every loop iteration:
- Active handlers (with events): poll.ns is updated using a
weighted average of the current block_ns and previous poll.ns,
smoothing out adjustments and preventing excessive fluctuations.
- Inactive handlers (no events): poll.ns accumulates block_ns
without weighting, allowing rapid isolation of idle nodes. When
poll.ns exceeds poll_max_ns, it resets to 0, preventing
sporadically active handlers from unnecessarily prolonging
iothread polling.
- The iothread polling duration is set based on the largest poll.ns
among active handlers. The shrink divider defaults to 2, matching
the grow rate, to reduce frequent poll_ns resets for slow devices.
The implementation renames poll_idle_timeout to last_dispatch_timestamp
for use as an active handler identifier.
Testing:
POLL_WEIGHT_SHIFT=3 (12.5% weight) was selected based on testing
comparing baseline vs weight=2/3 across various workloads:
Performance results (RHEL 10.1 + QEMU 10.0.0, FCP/FICON, 1-8 iothreads,
numjobs 1/4/8 averaged):
| poll-weight=2 | poll-weight=3
--------------------|--------------------|-----------------
Throughput avg | -2.4% (all tests) | -2.2% (all tests)
CPU consumption avg | -10.9% (all tests) | -9.4% (all tests)
Both configurations achieve ~10% CPU reduction with minimal throughput
impact (~2%). Weight=3 is chosen as default for slightly better
throughput while maintaining substantial CPU savings.
Additional validation testing on s390x SSD with fio (bs=8k, iodepth=8,
numjobs=1) shows how poll_weight affects polling time (poll.ns)
behavior:
RandRead workload:
+-------------+-----------+-----------+-------------+-------------+
| poll_weight | #samples | Mean (ns) | 50th % (ns) | 90th % (ns) |
+-------------+-----------+-----------+-------------+-------------+
| 1 | 4.79M | 8,034 | 5,116 | 20,509 |
| 2 | 5.01M | 12,584 | 11,078 | 24,693 |
| 3 | 5.01M | 15,647 | 14,863 | 28,695 |
| 4 | 5.12M | 16,430 | 15,556 | 30,848 |
| 5 | 5.14M | 16,461 | 15,306 | 32,123 |
+-------------+-----------+-----------+-------------+-------------+
RandWrite workload:
+-------------+-----------+-----------+-------------+-------------+
| poll_weight | #samples | Mean (ns) | 50th % (ns) | 90th % (ns) |
+-------------+-----------+-----------+-------------+-------------+
| 1 | 6.37M | 2,049 | 1,262 | 4,301 |
| 2 | 7.46M | 4,118 | 3,226 | 7,476 |
| 3 | 7.97M | 7,034 | 5,984 | 11,645 |
| 4 | 7.96M | 12,789 | 11,362 | 20,040 |
| 5 | 7.82M | 22,992 | 20,644 | 32,768 |
+-------------+-----------+-----------+-------------+-------------+
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Message-ID: <20260423195918.661299-3-jhkim@linux.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>