Re: [Qemu-devel] [PATCH v4 00/10] main-loop: switch to g_poll(3) on POSIX hosts

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

> Il 21/02/2013 17:29, Jan Kiszka ha scritto:
>> In this context, I'd like to recall a detail: Real-time prioritization
>> of those I/O threads will most probably require locking with
>> prio-inversion avoidance (*). In that case external libs without a
>> chance to tune or replace their internal locking (like glib) will be a
>> no-go for those kind of I/O threads.
>> 
>> The glib mainloop might be fine for all the rest, but we will likely
>> also need event loops with RT-compatible locking. So this refactoring
>> should keep the door open for alternative implementations.
>
> Yes, this refactoring is fine.  It doesn't use the glib mainloop any
> more than before.  AioContext is fine as an RT-compatible event loop.
> You can use both as a GSource or manually from a separate thread.
>
> What would be more problematic is the chardev flow control patches,
> which use the glib main loop directly.  I don't recall your KVM forum
> presentation---did you need RT prioritization of the serial port too?

It uses GSources which don't need a full glib main loop.  We just need
to be able to support glib event dispatch from whatever our main loop
is.

I would assume that we'd treat any glib event with the same priority if
we ever had a RT-iothread.

Regards,

Anthony Liguori

>
> Paolo
>
>> Jan
>> 
>> (*) Scenario: RT-iothread with highest prio wants to take a lock that is
>> held briefly by low-prio maintenance thread which is interrupted by
>> long-running medium-prio VCPU thread. This can delay or prevent the
>> event injection. Of course, this depends on the existence of such
>> dependencies.