The Thursday 31 Jul 2014 à 11:55:28 (+0800), Ming Lei wrote : > On Thu, Jul 31, 2014 at 7:37 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > Il 30/07/2014 19:15, Ming Lei ha scritto: > >> On Wed, Jul 30, 2014 at 9:45 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > >>> Il 30/07/2014 13:39, Ming Lei ha scritto: > >>>> This patch introduces several APIs for supporting bypass qemu coroutine > >>>> in case of being not necessary and for performance's sake. > >>> > >>> No, this is wrong. Dataplane *must* use the same code as non-dataplane, > >>> anything else is a step backwards. > >> > >> As we saw, coroutine has brought up performance regression > >> on dataplane, and it isn't necessary to use co in some cases, is it? > > > > Yes, and it's not necessary on non-dataplane either. It's not necessary > > on virtio-scsi, and it will not be necessary on virtio-scsi dataplane > > either. > > It is good to know these cases, so they might benefit from this patch > in future too, :-) > > >>> If you want to bypass coroutines, bdrv_aio_readv/writev must detect the > >>> conditions that allow doing that and call the bdrv_aio_readv/writev > >>> directly. > >> > >> That is easy to detect, please see the 5th patch. > > > > No, that's not enough. Dataplane right now prevents block jobs, but > > that's going to change and it could require coroutines even for raw devices. > > Could you explain it a bit why co is required for raw devices in future?
Block mirroring of a device for example is done using coroutines. As block mirroring can be done on a raw device you need coroutines. > > If some cases for not requiring co can be detected beforehand, these > patches are useful, IMO. > > >>> To begin with, have you benchmarked QEMU and can you provide a trace of > >>> *where* the coroutine overhead lies? > >> > >> I guess it may be caused by the stack switch, at least in one of > >> my box, bypassing co can improve throughput by ~7%, and by > >> ~15% in another box. > > > > No guesses please. Actually that's also my guess, but since you are > > submitting the patch you must do better and show profiles where stack > > switching disappears after the patches. > > OK, no problem, I will provide some profile result. > > Thanks, >