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

[Stefan Hajnoczi]

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 <address@hidden> 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