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

[Jan Kiszka]

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.

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