Re: Approaches to making io_submit not block

[Avi Kivity <avi@redhat.com>]

On 08/31/2011 06:45 PM, Gleb Natapov wrote:
> KVM also have similar needs. KVM has x86 emulator in kernel which is,
> in fact, a state machines that sometimes need an input from userspace
> to proceed.  Currently, when userspace input is needed, KVM goes back
> to userspace to retrieve the input and than retries the emulation. Some
> instructions may require several such iterations. This is somewhat similar
> to aio except that in KVM case emulation waits for userspace instead of
> disk/network HW. The resulting code is complex and error prone. It would
> be nice to not have to unwind the stack from the middle of the emulator
> just to be able to exit to userspace to retrieve the value. One idea that
> came up was to execute emulator on separate kernel stack (withing same
> task). When emulator needs a value from userspace it sleeps while main
> stack goes to userspace to get the value. When the value is available
> main stack wakes up emulator stack and emulation continues from the
> place it was stopped. Cooperative multithreading inside the kernel
> if you want. Bellow is the patch I prototyped to implement that on
> x86_64. I made KVM x86 emulator to use it too. I think AIO can use the
> same technique. io_submit will execute IO on alternative stack. If it
> blocks main thread will continue to run. When IO is completed IO stack
> will resume (alternative stack has priority over main stack).
>

Note that kvm has a significant interest in linux-aio as well - we see a 
significant performance win when we can use it.  From my point of view 
extending linux-aio to be truly asynchronous in all cases is the bigger 
win here, the emulator issue is a nice code cleanup but we could live 
without it.

-- 
error compiling committee.c: too many arguments to function