Message ID | 20201221192506.707584-1-eric.dumazet@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | e7e518053c267bb6be3799520d9f4a34c7264a2e |
Delegated to: | BPF |
Headers | show |
Series | [bpf] bpf: add schedule point in htab_init_buckets() | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Clearly marked for bpf |
netdev/subject_prefix | success | Link |
netdev/cc_maintainers | warning | 5 maintainers not CCed: kpsingh@kernel.org john.fastabend@gmail.com andrii@kernel.org yhs@fb.com kafai@fb.com |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 17 this patch: 17 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | warning | WARNING: 'Reported-by:' is the preferred signature form |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 17 this patch: 17 |
netdev/header_inline | success | Link |
netdev/stable | success | Stable not CCed |
> On Dec 21, 2020, at 11:25 AM, Eric Dumazet <eric.dumazet@gmail.com> 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 <jsperbeck@google.com> > Cc: Song Liu <songliubraving@fb.com> Acked-by: Song Liu <songliubraving@fb.com> Thanks for the fix! > --- > kernel/bpf/hashtab.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c > index 7e848200cd268a0f9ed063f0b641d3c355787013..c1ac7f964bc997925fd427f5192168829d812e5d 100644 > --- a/kernel/bpf/hashtab.c > +++ b/kernel/bpf/hashtab.c > @@ -152,6 +152,7 @@ static void htab_init_buckets(struct bpf_htab *htab) > lockdep_set_class(&htab->buckets[i].lock, > &htab->lockdep_key); > } > + cond_resched(); > } > } > > -- > 2.29.2.729.g45daf8777d-goog >
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. > > [...] Here is the summary with links: - [bpf] bpf: add schedule point in htab_init_buckets() https://git.kernel.org/bpf/bpf/c/e7e518053c26 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 7e848200cd268a0f9ed063f0b641d3c355787013..c1ac7f964bc997925fd427f5192168829d812e5d 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -152,6 +152,7 @@ static void htab_init_buckets(struct bpf_htab *htab) lockdep_set_class(&htab->buckets[i].lock, &htab->lockdep_key); } + cond_resched(); } }