From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrOvN-0001tA-IO for qemu-devel@nongnu.org; Fri, 13 Dec 2013 04:20:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrOvE-0002jk-WC for qemu-devel@nongnu.org; Fri, 13 Dec 2013 04:20:45 -0500 Received: from mail-ea0-x235.google.com ([2a00:1450:4013:c01::235]:44011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrOvE-0002je-Nq for qemu-devel@nongnu.org; Fri, 13 Dec 2013 04:20:36 -0500 Received: by mail-ea0-f181.google.com with SMTP id m10so725080eaj.26 for ; Fri, 13 Dec 2013 01:20:36 -0800 (PST) Date: Fri, 13 Dec 2013 10:20:32 +0100 From: Stefan Hajnoczi Message-ID: <20131213092032.GB2961@stefanha-thinkpad.redhat.com> References: <1386854384-1992-1-git-send-email-stefanha@redhat.com> <1386854384-1992-4-git-send-email-stefanha@redhat.com> <20131212180012.11040.17183@loki> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131212180012.11040.17183@loki> Subject: Re: [Qemu-devel] [RFC 3/7] iothread: add I/O thread object List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, Stefan Hajnoczi On Thu, Dec 12, 2013 at 12:00:12PM -0600, Michael Roth wrote: > Quoting Stefan Hajnoczi (2013-12-12 07:19:40) > > +static void *iothread_run(void *opaque) > > +{ > > + IOThread *iothread = opaque; > > + > > + for (;;) { > > + /* TODO can we optimize away acquire/release to only happen when > > + * aio_notify() was called? > > + */ > > Perhaps have the AioContext's notifier callback set a flag that can be > checked for afterward to determine whether we should release/re-acquire? > Calls to aio_context_acquire() could reset it upon acquistion, so we could > maybe do something like: > > while(!iothread->stopping) { > aio_context_acquire(iothread->ctx); > while (!iothread->ctx->notified) { > aio_poll(iothread->ctx, true); > } > aio_context_release(iothread->ctx); > } When aio_notify() kicks aio_poll() it returns false. So I was thinking of: while (!iothread->stopping) { aio_context_acquire(iothread->ctx); while (!iothread->stopping && aio_poll(iothread->ctx, true)) { /* Progress was made, keep going */ } aio_context_release(iothread->ctx); } I'll try it in the next version. Just didn't want to get too fancy yet. > > > + aio_context_acquire(iothread->ctx); > > + if (iothread->stopping) { > > + aio_context_release(iothread->ctx); > > + break; > > + } > > + aio_poll(iothread->ctx, true); > > + aio_context_release(iothread->ctx); > > + } > > + return NULL; > > +} > > + > > +static void iothread_instance_init(Object *obj) > > +{ > > + IOThread *iothread = IOTHREAD(obj); > > + > > + iothread->stopping = false; > > + iothread->ctx = aio_context_new(); > > + > > + /* This assumes .instance_init() is called from a thread with useful CPU > > + * affinity for us to inherit. > > + */ > > Is this assumption necessary/controllable? Couldn't we just expose the thread > id via QOM or some other interface so users/management can set the affinity > later? This assumption holds since the monitor and command-line run in the main thread. The fix has traditionally been to create the thread from a BH scheduled in the main loop. That way it inherits the main thread's affinity. We definitely need to expose tids via QOM/QMP. That's something I'm looking at QContext for. Did you already implement an interface? Stefan