[bpf-next v2 1/1] bpf: Mitigate latency spikes associated with freeing non-preallocated htab

[bpf-next v2 1/1] bpf: Mitigate latency spikes associated with freeing non-preallocated htab

[Yafang Shao]

Following the recent upgrade of one of our BPF programs, we encountered
significant latency spikes affecting other applications running on the same
host. After thorough investigation, we identified that these spikes were
primarily caused by the prolonged duration required to free a
non-preallocated htab with approximately 2 million keys.

Notably, our kernel configuration lacks the presence of CONFIG_PREEMPT. In
scenarios where kernel execution extends excessively, other threads might
be starved of CPU time, resulting in latency issues across the system. To
mitigate this, we've adopted a proactive approach by incorporating
cond_resched() calls within the kernel code. This ensures that during
lengthy kernel operations, the scheduler is invoked periodically to provide
opportunities for other threads to execute.

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>

---
v2: Call cond_resched() in the outer loop (Yonghong)
---
 kernel/bpf/hashtab.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 3a088a5349bc..e81059faae63 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -1490,6 +1490,7 @@ static void delete_all_elements(struct bpf_htab *htab)
 			hlist_nulls_del_rcu(&l->hash_node);
 			htab_elem_free(htab, l);
 		}
+		cond_resched();
 	}
 	migrate_enable();
 }
-- 
2.39.1

Re: [bpf-next v2 1/1] bpf: Mitigate latency spikes associated with freeing non-preallocated htab

[Yonghong Song]

On 3/26/24 8:20 PM, Yafang Shao wrote:
> Following the recent upgrade of one of our BPF programs, we encountered
> significant latency spikes affecting other applications running on the same
> host. After thorough investigation, we identified that these spikes were
> primarily caused by the prolonged duration required to free a
> non-preallocated htab with approximately 2 million keys.
>
> Notably, our kernel configuration lacks the presence of CONFIG_PREEMPT. In
> scenarios where kernel execution extends excessively, other threads might
> be starved of CPU time, resulting in latency issues across the system. To
> mitigate this, we've adopted a proactive approach by incorporating
> cond_resched() calls within the kernel code. This ensures that during
> lengthy kernel operations, the scheduler is invoked periodically to provide
> opportunities for other threads to execute.
>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>

LGTM.

Acked-by: Yonghong Song <yonghong.song@linux.dev>

Re: [bpf-next v2 1/1] bpf: Mitigate latency spikes associated with freeing non-preallocated htab

[patchwork-bot+netdevbpf]

Hello:

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

On Wed, 27 Mar 2024 11:20:22 +0800 you wrote:
> Following the recent upgrade of one of our BPF programs, we encountered
> significant latency spikes affecting other applications running on the same
> host. After thorough investigation, we identified that these spikes were
> primarily caused by the prolonged duration required to free a
> non-preallocated htab with approximately 2 million keys.
> 
> Notably, our kernel configuration lacks the presence of CONFIG_PREEMPT. In
> scenarios where kernel execution extends excessively, other threads might
> be starved of CPU time, resulting in latency issues across the system. To
> mitigate this, we've adopted a proactive approach by incorporating
> cond_resched() calls within the kernel code. This ensures that during
> lengthy kernel operations, the scheduler is invoked periodically to provide
> opportunities for other threads to execute.
> 
> [...]

Here is the summary with links:
  - [bpf-next,v2,1/1] bpf: Mitigate latency spikes associated with freeing non-preallocated htab
    https://git.kernel.org/bpf/bpf-next/c/cb7b8322017e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html