On Thu, Feb 21, 2013 at 05:29:25PM +0100, Jan Kiszka wrote: > 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.
What is stopping glib from becoming RT-friendly? Stefan