[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4823a44-33a9-4dbf-a39d-66ae256b903a@kernel.org>
Date: Wed, 6 Dec 2023 12:15:36 -0700
From: David Ahern <dsahern@...nel.org>
To: Doug Anderson <dianders@...omium.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
On 12/6/23 11:49 AM, Doug Anderson wrote:
> 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
yes, multitasking fail :-(
Powered by blists - more mailing lists