[ovs-dev] [PATCH v3 1/2] Optimize the poll loop for poll_immediate_wake()

Anton Ivanov anton.ivanov at cambridgegreys.com
Tue Jul 20 17:26:48 UTC 2021


On 19/07/2021 21:52, Ben Pfaff wrote:
> On Fri, Jul 16, 2021 at 02:42:32PM +0100, anton.ivanov at cambridgegreys.com wrote:
>> From: Anton Ivanov <anton.ivanov at cambridgegreys.com>
>>
>> If we are not obtaining any useful information out of the poll(),
>> such as is a fd busy or not, we do not need to do a poll() if
>> an immediate_wake() has been requested.
>>
>> This cuts out all the pollfd hash additions, forming the poll
>> arguments and the actual poll() after a call to
>> poll_immediate_wake()
>>
>> Signed-off-by: Anton Ivanov <anton.ivanov at cambridgegreys.com>
> Thanks for v3.
>
> I believe that the existing code here properly handles the pathological
> case where the current time is less than 0.  This is a case that I have
> seen happen on real systems that have a real-time clock with a bad
> current time and do not have proper support for a monotonic clock.  I
> believe that your new code does not properly handle this case, because
> it treats all times less than 0 as immediate.  I think that you can fix
> it by comparing against LLONG_MIN rather than zero.
>
> In poll-loop, I would move
>          COVERAGE_INC(poll_zero_timeout);
> inside the new statement that is already conditional on timeout_when ==
> LLONG_MIN.
>
> I don't like the new assumption in time_poll() that n_pollfds == 0 means
> we're waking immediately.
>
> Thanks,
>
> Ben.
>
Updated, all logic is now strictly based on timeout == LLONG_MIN.

I got a weird test failure from the build robot which I cannot reproduce. I ran the test which failed ~ 100 iterations and then the test suite for about an hour. No failures.

Best Regards,

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/



More information about the dev mailing list