Re: [Qemu-devel] [regression] dataplane: throughout -40% by commit 580b6b2aa2

[Paolo Bonzini <pbonzini@redhat.com>]

Il 02/07/2014 11:39, Kevin Wolf ha scritto:
> Am 02.07.2014 um 11:13 hat Paolo Bonzini geschrieben:
> I don't think starting with that fast path as _the_ solution is a good
> idea. It would essentially restrict dataplane to the scenarios that used
> to work well in 2.0 - just look at what the block.c read/write functions
> do: no image formats, (almost?) no block jobs, no 4k sector support, no
> writethrough mode, no zero detection, no throttling, no nothing.
> Anything we want to keep while using the fast path we would have to
> duplicate there.

You're entirely right (I wouldn't duplicate it though, I would just 
sacrifice it).  But I think none of the bullets apply in maximum 
performance situations, and fast paths are okay as long as they are 
picked dynamically at run-time.

>>> Another idea is to skip aio_notify() when we're sure the event loop
>>> isn't blocked in g_poll().  Doing this is a thread-safe and lockless way
>>> might be tricky though.
>>
>> Yes, good idea for 2.2 but not now.
>
> Isn't it a first approximation that it's unnecessary when we're already
> running in the thread with the AIO main loop? (Which pretty much means
> always with dataplane.) Or can it be required even when we don't switch
> to a different thread?

That's not even that much of an approximation.  I think it's pretty much 
the definition of when it's unnecessary.  Clever!

An approximation is "it's unnecessary if we have the aio context lock 
taken".  Which is also always the case with dataplane, but never with 
non-dataplane (the main loop bypasses aio_context_acquire/release). 
Adding rfifolock_is_owned is trivial.

Paolo