qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 00/17] Support for multiple "AIO contexts"


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC PATCH 00/17] Support for multiple "AIO contexts"
Date: Mon, 8 Oct 2012 13:39:32 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Sep 25, 2012 at 02:55:46PM +0200, Paolo Bonzini wrote:
> This series removes the globals from async.c/aio-posix.c so that
> multiple AIO contexts (mini event loops) can be added.  Right now,
> all block devices still use qemu_bh_new, but switching them to
> aio_bh_new would let you associate different files with different
> AIO contexts.
> 
> As an added bonus, integration with the glib main loop now happens
> via GSource.  Each AIO context is a GSource, which means you can
> choose either to run it in its own thread (this of course needs
> proper locking which is not yet here), or to attach it to the main
> thread.
> 
> In this state this is a bit of an academic exercise (though it works
> and may even make sense for 1.3), but I think it's an example of the
> tiny steps that can lead us towards an upstreamable version of the
> data-plane code.
> 
> Paolo
> 
> Paolo Bonzini (17):
>   build: do not rely on indirect inclusion of qemu-config.h
>   event_notifier: enable it to use pipes
>   event_notifier: add Win32 implementation
>   aio: change qemu_aio_set_fd_handler to return void
>   aio: provide platform-independent API
>   aio: introduce AioContext, move bottom halves there
>   aio: add I/O handlers to the AioContext interface
>   aio: add non-blocking variant of aio_wait
>   aio: prepare for introducing GSource-based dispatch
>   aio: add Win32 implementation
>   aio: make AioContexts GSources
>   aio: add aio_notify
>   aio: call aio_notify after setting I/O handlers
>   main-loop: use GSource to poll AIO file descriptors
>   main-loop: use aio_notify for qemu_notify_event
>   aio: clean up now-unused functions
>   linux-aio: use event notifiers
> 
>  Makefile.objs                              |   6 +-
>  aio.c => aio-posix.c                       | 159 +++++++++++++++-------
>  aio.c => aio-win32.c                       | 190 ++++++++++++++------------
>  async.c                                    | 118 ++++++++++++++---
>  block/Makefile.objs                        |   6 +-
>  block/blkdebug.c                           |   1 +
>  block/iscsi.c                              |   1 +
>  event_notifier.c => event_notifier-posix.c |  83 +++++++++---
>  event_notifier.c => event_notifier-win32.c |  48 +++----
>  event_notifier.h                           |  20 ++-
>  hw/hw.h                                    |   1 +
>  iohandler.c                                |   1 +
>  linux-aio.c                                |  49 +++----
>  main-loop.c                                | 152 +++++++--------------
>  main-loop.h                                |  56 +-------
>  oslib-posix.c                              |  31 -----
>  qemu-aio.h                                 | 206 
> +++++++++++++++++++++++++++--
>  qemu-char.h                                |   1 +
>  qemu-common.h                              |   2 +-
>  qemu-config.h                              |   1 +
>  qemu-coroutine-lock.c                      |   2 +-
>  qemu-os-win32.h                            |   1 -
>  22 file modificati, 702 inserzioni(+), 433 rimozioni(-)
>  copy aio.c => aio-posix.c (48%)
>  rename aio.c => aio-win32.c (44%)
>  copy event_notifier.c => event_notifier-posix.c (36%)
>  rename event_notifier.c => event_notifier-win32.c (49%)

This series looks useful - it compartmentalizes aio.c so there can be multiple
event loops.  In order to get a performance benefit (hooking up virtio-blk
ioeventfd to a non-QEMU mutex thread) we need two more things:

1. Block layer association with an AioContext (perhaps BlockDriverState <->
   AioContext attaching).

2. Thread pool for dispatching I/O requests outside the QEMU global mutex.

I'm starting to work on these steps and will send RFCs.  This series looks good
to me.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]