[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=UgPZoXsGTgLV_4X9x2hGTMouO3Tpe9_WkwhU7Bsvav2Q@mail.gmail.com>
Date: Wed, 6 Dec 2023 10:49:29 -0800
From: Doug Anderson <dianders@...omium.org>
To: David Ahern <dsahern@...nel.org>
Cc: Stephen Hemminger <stephen@...workplumber.org>, Judy Hsiao <judyhsiao@...omium.org>,
Eric Dumazet <edumazet@...gle.com>, Simon Horman <horms@...nel.org>,
Brian Haley <haleyb.dev@...il.com>, "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Joel Granados <joel.granados@...il.com>, Julian Anastasov <ja@....bg>,
Leon Romanovsky <leon@...nel.org>, Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH v2] neighbour: Don't let neigh_forced_gc() disable
preemption for long
Hi,
On Wed, Dec 6, 2023 at 9:51 AM David Ahern <dsahern@...nel.org> wrote:
>
> On 12/6/23 10:39 AM, Stephen Hemminger wrote:
> > On Wed, 6 Dec 2023 03:38:33 +0000
> > Judy Hsiao <judyhsiao@...omium.org> wrote:
> >
> >> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> >> index df81c1f0a570..552719c3bbc3 100644
> >> --- a/net/core/neighbour.c
> >> +++ b/net/core/neighbour.c
> >> @@ -253,9 +253,11 @@ static int neigh_forced_gc(struct neigh_table *tbl)
> >> {
> >> int max_clean = atomic_read(&tbl->gc_entries) -
> >> READ_ONCE(tbl->gc_thresh2);
> >> + u64 tmax = ktime_get_ns() + NSEC_PER_MSEC;
> >> unsigned long tref = jiffies - 5 * HZ;
> >> struct neighbour *n, *tmp;
> >> int shrunk = 0;
> >> + int loop = 0;
> >>
> >> NEIGH_CACHE_STAT_INC(tbl, forced_gc_runs);
> >>
> >> @@ -278,11 +280,16 @@ static int neigh_forced_gc(struct neigh_table *tbl)
> >> shrunk++;
> >> if (shrunk >= max_clean)
> >> break;
> >> + if (++loop == 16) {
> >
> > Overall looks good.
> > Minor comments:
> > - loop count should probably be unsigned
> > - the magic constant 16 should be a sysctl tuneable
>
> A tunable is needed here; the loop counter is just to keep the overhead
> of the ktime_get_ns call in check.
>From context, I'm going to assume you meant a tunable is _NOT_ needed here. ;-)
-Doug
Powered by blists - more mailing lists