From: Eric Dumazet <hidden> Date: 2020-12-21 19:26:02
From: Eric Dumazet <edumazet@google.com>
We noticed that with a LOCKDEP enabled kernel,
allocating a hash table with 65536 buckets would
use more than 60ms.
htab_init_buckets() runs from process context,
it is safe to schedule to avoid latency spikes.
Fixes: c50eb518e262 ("bpf: Use separate lockdep class for each hashtab")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-By: John Sperbeck <redacted>
Cc: Song Liu <redacted>
---
kernel/bpf/hashtab.c | 1 +
1 file changed, 1 insertion(+)
On Dec 21, 2020, at 11:25 AM, Eric Dumazet [off-list ref] wrote:
From: Eric Dumazet <edumazet@google.com>
We noticed that with a LOCKDEP enabled kernel,
allocating a hash table with 65536 buckets would
use more than 60ms.
htab_init_buckets() runs from process context,
it is safe to schedule to avoid latency spikes.
Fixes: c50eb518e262 ("bpf: Use separate lockdep class for each hashtab")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-By: John Sperbeck <redacted>
Cc: Song Liu <redacted>
Hello:
This patch was applied to bpf/bpf.git (refs/heads/master):
On Mon, 21 Dec 2020 11:25:06 -0800 you wrote:
From: Eric Dumazet <edumazet@google.com>
We noticed that with a LOCKDEP enabled kernel,
allocating a hash table with 65536 buckets would
use more than 60ms.
htab_init_buckets() runs from process context,
it is safe to schedule to avoid latency spikes.
[...]