[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQL9naBBKzQdAOWu2ZH=i7HA1VDi7uNzsDQ1TM9Jr+c0Ww@mail.gmail.com>
Date: Thu, 19 May 2022 09:12:04 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Feng Zhou <zhoufeng.zf@...edance.com>
Cc: Yonghong Song <yhs@...com>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Network Development <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Xiongchun Duan <duanxiongchun@...edance.com>,
Muchun Song <songmuchun@...edance.com>,
Dongdong Wang <wangdongdong.6@...edance.com>,
Cong Wang <cong.wang@...edance.com>,
Chengming Zhou <zhouchengming@...edance.com>
Subject: Re: [External] Re: [PATCH] bpf: avoid grabbing spin_locks of all cpus
when no free elems
On Wed, May 18, 2022 at 8:12 PM Feng Zhou <zhoufeng.zf@...edance.com> wrote:
>
> 在 2022/5/19 上午4:39, Yonghong Song 写道:
> >
> >
> > On 5/17/22 11:57 PM, Feng Zhou wrote:
> >> 在 2022/5/18 下午2:32, Alexei Starovoitov 写道:
> >>> On Tue, May 17, 2022 at 11:27 PM Feng zhou
> >>> <zhoufeng.zf@...edance.com> wrote:
> >>>> From: Feng Zhou <zhoufeng.zf@...edance.com>
> >>>>
> >>>> We encountered bad case on big system with 96 CPUs that
> >>>> alloc_htab_elem() would last for 1ms. The reason is that after the
> >>>> prealloc hashtab has no free elems, when trying to update, it will
> >>>> still
> >>>> grab spin_locks of all cpus. If there are multiple update users, the
> >>>> competition is very serious.
> >>>>
> >>>> So this patch add is_empty in pcpu_freelist_head to check freelist
> >>>> having free or not. If having, grab spin_lock, or check next cpu's
> >>>> freelist.
> >>>>
> >>>> Before patch: hash_map performance
> >>>> ./map_perf_test 1
> >
> > could you explain what parameter '1' means here?
>
> This code is here:
> samples/bpf/map_perf_test_user.c
> samples/bpf/map_perf_test_kern.c
> parameter '1' means testcase flag, test hash_map's performance
> parameter '2048' means test hash_map's performance when free=0.
> testcase flag '2048' is added by myself to reproduce the problem phenomenon.
Please convert it to selftests/bpf/bench,
so that everyone can reproduce the issue you're seeing
and can assess whether it's a real issue or a corner case.
Also please avoid adding indent in the patch.
Instead of
if (!s->extralist.is_empty) {
.. churn
do
if (s->extralist.is_empty)
Powered by blists - more mailing lists