CLEANUP: stream: explain why we queue the stream at the head of the server list

In stream_add_srv_conn() MT_LIST_ADD() is used instead of MT_LIST_ADDQ(),
resulting in the stream being queued at the end of the server list. This
has no particular effect since we cannot dump the streams on a server,
and this is only used by "shutdown sessions" on a server. But it also
turns out to be significantly faster due to the shorter recovery from
the conflict with an adjacent MT_LIST_DEL(), thus it remains desirable
to use it, but at least it deserves a comment.

In addition to this, it's worth mentioning that this list should creates
extreme contention with threads while almost never used. It should be
made per-thread just like the global streams list.

diff --git a/include/haproxy/stream.h b/include/haproxy/stream.h
index d4d202b2f87397b9b9c703f2ec615aae44c3bbf5..8daf2adcc7af7fe73e798257de5d84d5a6826d56 100644 (file)
--- a/include/haproxy/stream.h
+++ b/include/haproxy/stream.h
@@ -286,6 +286,12 @@ static inline void stream_inc_http_fail_ctr(struct stream *s)
 
 static inline void stream_add_srv_conn(struct stream *sess, struct server *srv)
 {
+       /* note: this inserts in reverse order but we do not care, it's only
+        * used for massive kills (i.e. almost never). MT_LIST_ADD() is a bit
+        * faster than MT_LIST_ADDQ under contention due to a faster recovery
+        * from a conflict with an adjacent MT_LIST_DEL, and using it improves
+        * the performance by about 3% on 32-cores.
+        */
        MT_LIST_ADD(&srv->actconns, &sess->by_srv);
        HA_ATOMIC_STORE(&sess->srv_conn, srv);
 }