From: Jakub Kicinski <kuba@kernel.org>
To: Vimal Agrawal <avimalin@gmail.com>, kuniyu@google.com
Cc: pabeni@redhat.com, netdev@vger.kernel.org, edumazet@google.com,
vimal.agrawal@sophos.com
Subject: Re: [PATCH v4 net-next] net: neigh: avoid calling neigh_forced_gc on every alloc when table is full
Date: Tue, 21 Jul 2026 14:09:11 -0700 [thread overview]
Message-ID: <20260721140911.2e12e60c@kernel.org> (raw)
In-Reply-To: <20260715055311.90403-1-vimal.agrawal@sophos.com>
On Wed, 15 Jul 2026 05:53:11 +0000 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, but only when the table actually contains
> NEIGH_FORCED_GC_LARGE_TABLE_THRESH (16384) or more entries. This avoids
> repeated full table scans and lock acquisitions on the hot allocation path
> while leaving tables with few entries completely unaffected regardless of
> how gc_thresh3 is configured.
Hi Kuniyuki, are you still unconvinced by this?
next prev parent reply other threads:[~2026-07-21 21:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 8:17 neigh: poor scalability of forced GC when neighbour count exceeds gc_thresh3 Vimal Agrawal
2026-06-25 10:20 ` [PATCH net-next] net: neigh: avoid calling neigh_forced_gc on every alloc when table is full Vimal Agrawal
2026-06-25 15:42 ` Jakub Kicinski
2026-07-06 6:58 ` [PATCH v2 " Vimal Agrawal
2026-07-06 14:19 ` Paolo Abeni
2026-07-14 13:39 ` [PATCH v3 " Vimal Agrawal
2026-07-15 5:53 ` [PATCH v4 " Vimal Agrawal
2026-07-21 21:09 ` Jakub Kicinski [this message]
2026-06-25 21:45 ` [PATCH " Kuniyuki Iwashima
2026-06-29 7:57 ` Vimal Agrawal
2026-06-29 18:05 ` Kuniyuki Iwashima
2026-06-30 12:01 ` Vimal Agrawal
2026-06-30 16:36 ` Kuniyuki Iwashima
2026-07-01 8:30 ` Vimal Agrawal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260721140911.2e12e60c@kernel.org \
--to=kuba@kernel.org \
--cc=avimalin@gmail.com \
--cc=edumazet@google.com \
--cc=kuniyu@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vimal.agrawal@sophos.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.