]> git.kaiwu.me - haproxy.git/commit
MEDIUM: connection: make the subscribe() call able to wakeup if ready
authorWilly Tarreau <w@1wt.eu>
Fri, 28 Feb 2020 13:24:49 +0000 (14:24 +0100)
committerWilly Tarreau <w@1wt.eu>
Fri, 28 Feb 2020 15:17:09 +0000 (16:17 +0100)
commit7e59c0a5e13df4611bb000d18465d363819373f2
tree49c62adca46b52b22ffe0eb414307125111e79a6
parent8dd348c90c5c6c5c7ea4a304a1e44692cd4a84ae
MEDIUM: connection: make the subscribe() call able to wakeup if ready

There's currently an internal API limitation at the connection layer
regarding conn_subscribe(). We must not subscribe if we haven't yet
met EAGAIN or such a condition, so we sometimes force ourselves to read
in order to meet this condition and being allowed to call subscribe.
But reading cannot always be done (e.g. at the end of a loop where we
cannot afford to retrieve new data and start again) so we instead
perform a tasklet_wakeup() of the requester's io_cb. This is what is
done in mux_h1 for example. The problem with this is that it forces
a new receive when we're not necessarily certain we need one. And if
the FD is not ready and was already being polled, it's a useless
wakeup.

The current patch improves the connection-level subscribe() so that
it really manipulates the polling if the FD is marked not-ready, but
instead schedules the argument tasklet for a wakeup if the FD is
ready. This guarantees we'll wake this tasklet up in any case once the
FD is ready, either immediately or after polling.

By doing so, a test on pure close mode shows we cut in half the number
of epoll_ctl() calls and almost eliminate failed recvfrom():

  $ ./h1load -n 100000 -r 1 -t 4 -c 1000 -T 20 -F 127.0.0.1:8001/?s=1k/t=20

  before:
   399464 epoll_ctl 1
   200007 recvfrom 1
   200000 sendto 1
   100000 recvfrom -1
     7508 epoll_wait 1

  after:
   205739 epoll_ctl 1
   200000 sendto 1
   200000 recvfrom 1
     6084 epoll_wait 1
     2651 recvfrom -1

On keep-alive there is no change however.
src/connection.c