On 7/6/26 8:58 AM, Vimal Agrawal wrote:

Once the neighbour table exceeds gc_thresh3, neigh_forced_gc() is called
on every allocation attempt with no rate limiting. In workloads with mostly
active/reachable entries, the GC walk traverses a large portion of the
neighbour table without reclaiming entries, holding tbl->lock for an
extended period. This causes severe lock contention and allocation
latencies exceeding 16ms under sustained neighbour creation.

Add a pre-lock check in neigh_forced_gc() to skip the GC run if one was
performed within the last 50 ms, avoiding repeated full table scans and
lock acquisitions on the hot allocation path.

Profiling of neigh_create() shows ~3 orders of magnitude latency
improvement with this change.

Link: https://lore.kernel.org/netdev/CALkUMdSCpx_ywYCx_ePLdm6yioO1nQWx7sSM=AEgsq0kywHxTw@mail.gmail.com/ (local)
Signed-off-by: Vimal Agrawal <redacted>

This apparently breaks neigh self-tests:

# 29.38 [+5.12] TEST: IPv4 "extern_valid" flag: Forced garbage
collection           [FAIL]
//...
# 85.91 [+5.11] TEST: IPv6 "extern_valid" flag: Forced garbage
collection           [FAIL]

full log at:

https://netdev-ctrl.bots.linux.dev/logs/vmksft/net/results/722145/13-test-neigh-sh/

/P