On Tue, Dec 19, 2017 at 1:33 PM, sochin.jiang <sochin.ji...@huawei.com> wrote:
> Till now, we've already notify guest as a batch mostly, an
> extra BH won't decrease guest interrupts much, but cause a
> significant notification loss. Generally, we could have 15%
> or so performance lost in single queue IO models, as I tested.
Recent performance testing has shown that virtio-blk can underperform
virtio-scsi due to the extra latency added by the BH.
The virtqueue EVENT_IDX feature mitigates interrupts when the guest
interrupt handler has not had a chance to run yet. Therefore, virtio
already offers one level of interrupt mitigation and the BH adds
additional latency on top.
The BH helps when the guest services interrupts very quickly
(defeating EVENT_IDX mitigation) and therefore the device raises
additional interrupts. Network drivers in Linux solve this using
NAPI, where the driver disables interrupts during periods of high
completion rates. We could do the same inside the guest driver and it
would not suffer from BH latency.
I now think that this patch would benefit most cases, although it may
harm the case mentioned above without further patches to the
virtio_blk.ko guest driver.
Please resend the patch with fio benchmark output in the commit
description and the issue I raised fixed:
> @@ -75,7 +67,12 @@ static void notify_guest_bh(void *opaque)
> -/* Context: QEMU global mutex held */
Please keep this doc comment for virtio_blk_data_plane_create().