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

[Paolo Bonzini]

Il 21/02/2013 17:08, Laszlo Ersek ha scritto:
> On 02/21/13 14:17, 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. 
> 
> There's a mitigating factor fwiw. It is true that an N times bigger
> array of fds takes N times longer for the kernel to check.

Actually this is not true for epoll, where the kernel pushes events as
they become available.  However, this...

> But "on
> average" there should be N times as many ready fds as well, which should
> take N times as long to process afterwards. Therefore you'd call poll()
> 1/Nth times as frequently. I think the efficiency ("bandwidth") would
> not necessarily sink as the array grows, but processing would indeed
> become more "chunky" ("latency" would rise between two checks of the
> same fd).

... remains very true.

The right thing to do would be to have a pool of threads that can
process file descriptors in parallel.  But implementing this in a
scalable (and correct!) way is insanely complex.  It is much simpler to
use many threads, especially if we can count on a pretty good scheduler
such as Linux's.

Paolo

> I'm not saying it's insignificant but perhaps not as catastrophic as
> expected.
> 
> Laszlo
>