tree a093f5a4eb03fdc1f3415c5c5e2d01262f122cd8
parent a7d6a1396ec9608e6b9d48093bc7996cafbd61b9
author Willy Tarreau <w@1wt.eu> 1665494562 +0200
committer Willy Tarreau <w@1wt.eu> 1665577145 +0200
encoding latin1

MEDIUM: stick-table: make stktable_get_entry() look up under a read lock

On a 24-core machine doing lots of track-sc, it was found that the lock
in stktable_get_entry() was responsible for 25% of the CPU alone. It's
sad because most of its job is to protect the table during the lookup.

Here we're taking a slightly different approach: the lock is first taken
for reads during the lookup, and only in case of failure we switch it for
a write lock. We don't even perform an upgrade here since an allocation
is needed between the two, it would be wasted to do it under the lock,
and is generally not a good idea, so better release the read lock and
try again.

Here the performance under 48 threads with 3 trackers on the same table
jumped from 455k to 2.07M, or 4.55x! Note that the same approach should
be possible for stktable_set_entry().