linux-kernel - Re: Approaches to making io

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 31 Aug 2011 19:02:24 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gleb Natapov <gleb@...hat.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Ehrenberg <dehrenberg@...gle.com>,
	Jens Axboe <axboe@...nel.dk>, Jeff Moyer <jmoyer@...hat.com>,
	linux-kernel@...r.kernel.org, linux-aio@...ck.org
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/