mirror of
https://github.com/qemu/qemu.git
synced 2026-07-08 17:46:10 +00:00
b756692ce1
FUSE allows creating multiple request queues by "cloning" /dev/fuse FDs
(via open("/dev/fuse") + ioctl(FUSE_DEV_IOC_CLONE)).
We can use this to implement multi-threading.
For configuration, we don't need any more information beyond the simple
array provided by the core block export interface: The FUSE kernel
driver feeds these FDs in a round-robin fashion, so all of them are
equivalent and we want to have exactly one per thread.
These are the benchmark results when using four threads (compared to a
single thread); note that fio still only uses a single job, but
performance can still be improved because of said round-robin usage for
the queues. (Not in the sync case, though, in which case I guess it
just adds overhead.)
file:
read:
seq aio: 261.7k ±1.7k (+168%)
rand aio: 129.2k ±14.3k (+35%)
seq sync: 36.6k ±0.6k (+6%)
rand sync: 10.1k ±0.1k (+2%)
write:
seq aio: 235.7k ±2.8k (+243%)
rand aio: 232.0k ±6.7k (+237%)
seq sync: 31.7k ±0.6k (+4%)
rand sync: 31.8k ±0.5k (+4%)
null:
read:
seq aio: 253.8k ±12.3k (+45%)
rand aio: 248.2k ±12.0k (+45%)
seq sync: 91.6k ±2.4k (+12%)
rand sync: 91.3k ±2.1k (+17%)
write:
seq aio: 208.2k ±9.8k (+6%)
rand aio: 207.0k ±7.4k (+8%)
seq sync: 91.2k ±1.9k (+9%)
rand sync: 90.4k ±2.5k (+14%)
So moderate improvements in most cases, but quite improved AIO
performance with an actual underlying file.
Here's results for numjobs=4:
"Before", i.e. without multithreading in QSD/FUSE (results compared to
numjobs=1):
file:
read:
seq aio: 85.5k ±0.4k (-13%)
rand aio: 92.5k ±0.5k (-3%)
seq sync: 54.5k ±9.1k (+58%)
rand sync: 38.0k ±0.2k (+283%)
write:
seq aio: 67.3k ±0.3k (-2%)
rand aio: 67.6k ±0.3k (-2%)
seq sync: 69.3k ±0.5k (+126%)
rand sync: 69.3k ±0.3k (+126%)
null:
read:
seq aio: 170.6k ±0.8k (-2%)
rand aio: 170.9k ±0.9k (±0%)
seq sync: 187.6k ±1.3k (+129%)
rand sync: 188.9k ±0.9k (+142%)
write:
seq aio: 191.5k ±1.2k (-2%)
rand aio: 193.8k ±1.4k (-1%)
seq sync: 206.1k ±1.3k (+147%)
rand sync: 206.1k ±1.2k (+159%)
As probably expected, little difference in the AIO case, but great
improvements in the sync cases because it kind of gives it an artificial
iodepth of 4.
"After", i.e. with four threads in QSD/FUSE (now results compared to the
above):
file:
read:
seq aio: 198.7k ±2.7k (+132%)
rand aio: 317.3k ±0.6k (+243%)
seq sync: 55.9k ±8.9k (+3%)
rand sync: 39.1k ±0.0k (+3%)
write:
seq aio: 229.0k ±0.8k (+240%)
rand aio: 227.0k ±1.3k (+235%)
seq sync: 102.5k ±0.2k (+48%)
rand sync: 101.7k ±0.2k (+47%)
null:
read:
seq aio: 584.0k ±1.5k (+242%)
rand aio: 581.9k ±1.9k (+240%)
seq sync: 270.6k ±0.9k (+44%)
rand sync: 270.4k ±0.7k (+43%)
write:
seq aio: 598.4k ±2.0k (+212%)
rand aio: 605.2k ±2.0k (+212%)
seq sync: 274.0k ±0.8k (+33%)
rand sync: 275.0k ±0.7k (+33%)
So this helps mainly for the AIO cases, but also in the null sync cases,
because null is always CPU-bound, so more threads help.
One unsolved mystery: When using a multithreaded export, running fio
with 1 job (benchmark at the top of this commit) yields better seqread
performance than doing so with 4 jobs. Actually, with 4 jobs, it's
significantly than randread, which is quite strange.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20260309150856.26800-24-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>