qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v4 00/10] main-loop: switch to g_poll(3) on POSIX hosts
Date: Thu, 21 Feb 2013 17:08:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12

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. 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).

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

Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]