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(). Thanks, Stefan
