[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 3/7] iothread: add I/O thread object
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC 3/7] iothread: add I/O thread object |
Date: |
Fri, 13 Dec 2013 10:20:32 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- [Qemu-devel] [RFC 0/7] dataplane: switch to N:M devices-per-thread model, Stefan Hajnoczi, 2013/12/12
- [Qemu-devel] [RFC 1/7] rfifolock: add recursive FIFO lock, Stefan Hajnoczi, 2013/12/12
- [Qemu-devel] [RFC 2/7] aio: add aio_context_acquire() and aio_context_release(), Stefan Hajnoczi, 2013/12/12
- [Qemu-devel] [RFC 3/7] iothread: add I/O thread object, Stefan Hajnoczi, 2013/12/12
- [Qemu-devel] [RFC 7/7] dataplane: replace internal thread with IOThread, Stefan Hajnoczi, 2013/12/12
- [Qemu-devel] [RFC 4/7] iothread: command-line option, Stefan Hajnoczi, 2013/12/12
- [Qemu-devel] [RFC 5/7] qdev: add get_pointer_and_free() for temporary strings, Stefan Hajnoczi, 2013/12/12
- [Qemu-devel] [RFC 6/7] iothread: add "iothread" qdev property type, Stefan Hajnoczi, 2013/12/12