Re: [Qemu-devel] [RFC 3/7] iothread: add I/O thread object

[Stefan Hajnoczi <stefanha@gmail.com>]

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