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

[Jan Kiszka]

On 2013-02-22 09:40, Stefan Hajnoczi wrote:
> 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?

It's not the target audience of glib.

RT means you care a lot about what happens underneath you, and glib is
much more about avoiding this detail knowledge. Also, RT is not as easy
portable as the simple internal and external locking primitives that
glib currently uses/supports. Even without RT use cases, we are already
unable to use glib's synchronization primitives for QEMU purposes.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux