Messages in this thread | | | Date | Wed, 31 Aug 2011 19:02:24 +0300 | From | Avi Kivity <> | Subject | Re: Approaches to making io_submit not block |
| |
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
| |