On 2013-02-21 16:33, Stefan Hajnoczi wrote: > On Thu, Feb 21, 2013 at 02:17:14PM +0100, Christian Borntraeger wrote: >> On 20/02/13 11:28, Stefan Hajnoczi wrote: >>> Amos Kong <ak...@redhat.com> reported that file descriptors numbered higher >>> than 1024 could crash QEMU. This is due to the fixed size of the fd_set >>> type >>> used for select(2) event polling. >>> >> >> Good to see somebody working on that. >> We have just faced this problem on s390 after we have experimentally enabled >> ioeventfd >> for virtio-ccw. We have several scenarios were we want > 600 devices for the >> guest >> and the select loops then fails horribly because we exceed the 1024 fd >> barrier. >> >> So this looks like it could become a bugfix for that problem. >> >> In terms of scalability it is probably better to have multiple threads that >> poll on their >> fds, instead of having one i/o thread. > > I think we'll get there, I'm currently working on adding multiple event > loop support to QEMU.
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. 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. -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
