Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v6 0/2] Optimize performance of update hash-map when free is
 zero
From:   patchwork-bot+netdevbpf@kernel.org
Message-Id: <165498361355.20267.7962671859794283090.git-patchwork-notify@kernel.org>
Date:   Sat, 11 Jun 2022 21:40:13 +0000
References: <20220610023308.93798-1-zhoufeng.zf@bytedance.com>
In-Reply-To: <20220610023308.93798-1-zhoufeng.zf@bytedance.com>
To:     Feng zhou <zhoufeng.zf@bytedance.com>
Cc:     ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
        kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
        john.fastabend@gmail.com, kpsingh@kernel.org,
        netdev@vger.kernel.org, bpf@vger.kernel.org,
        linux-kernel@vger.kernel.org, duanxiongchun@bytedance.com,
        songmuchun@bytedance.com, wangdongdong.6@bytedance.com,
        cong.wang@bytedance.com, zhouchengming@bytedance.com
Precedence: bulk

Hello:

This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Fri, 10 Jun 2022 10:33:06 +0800 you wrote:
> From: Feng Zhou <zhoufeng.zf@bytedance.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