Paolo Bonzini <[email protected]> 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.
