[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <165498361355.20267.7962671859794283090.git-patchwork-notify@kernel.org>
Date: Sat, 11 Jun 2022 21:40:13 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Feng zhou <zhoufeng.zf@...edance.com>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
kafai@...com, songliubraving@...com, yhs@...com,
john.fastabend@...il.com, kpsingh@...nel.org,
netdev@...r.kernel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, duanxiongchun@...edance.com,
songmuchun@...edance.com, wangdongdong.6@...edance.com,
cong.wang@...edance.com, zhouchengming@...edance.com
Subject: Re: [PATCH v6 0/2] Optimize performance of update hash-map when free is
zero
Hello:
This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@...nel.org>:
On Fri, 10 Jun 2022 10:33:06 +0800 you 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.
>
> [...]
Here is the summary with links:
- [v6,1/2] bpf: avoid grabbing spin_locks of all cpus when no free elems
https://git.kernel.org/bpf/bpf-next/c/54a9c3a42d92
- [v6,2/2] selftest/bpf/benchs: Add bpf_map benchmark
https://git.kernel.org/bpf/bpf-next/c/89eda98428ce
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists