tree 1f507b9a64552c99fd5988d39411d45a461376f1
parent 83b30c1e3c6467adbfcd398ac8371d8a2ae63226
author Willy Tarreau <w@1wt.eu> 1211704742 +0200
committer Willy Tarreau <w@1wt.eu> 1211704742 +0200
encoding latin1

[MEDIUM] reduce risk of event starvation in ev_sepoll

If too many events are set for spec I/O, those ones can starve the
polled events. Experiments show that when polled events starve, they
quickly turn into spec I/O, making the situation even worse. While
we can reduce the number of polled events processed at once, we
cannot do this on speculative events because most of them are new
ones (avg 2/3 new - 1/3 old from experiments).

The solution against this problem relies on those two factors :
  1) one FD registered as a spec event cannot be polled at the same time
  2) even during very high loads, we will almost never be interested in
     simultaneous read and write streaming on the same FD.

The first point implies that during starvation, we will not have more than
half of our FDs in the poll list, otherwise it means there is less than that
in the spec list, implying there is no starvation.

The second point implies that we're statically only interested in half of
the maximum number of file descriptors at once, because we will unlikely
have simultaneous read and writes for a same buffer during long periods.

So, if we make it possible to drain maxsock/2/2 during peak loads, then we
can ensure that there will be no starvation effect. This means that we must
always allocate maxsock/4 events for the poller.

Last, sepoll uses an optimization consisting in reducing the number of calls
to epoll_wait() to once every too polls. However, when dealing with many
spec events, we can wait very long and skipping epoll_wait() every second
time increases latency. For this reason, we try to detect if we are beyond
a reasonable limit and stop doing so at this stage.