-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long start time on bpf-next (6.4-rc3) #189
Comments
Until #189 has been fixed. Signed-off-by: Martynas Pumputis <m@lambda.lt>
Until #189 has been fixed. Signed-off-by: Martynas Pumputis <m@lambda.lt>
Ouch! 😅 Definitely a cilium/ebpf issue. Mind moving the issue? NVM, I'll create a new one. |
I also confirm that It consumes 10m1.519248586s of 10m21.610184033s My running env is 6.2 kernel on Ubuntu 23.04 VM built from server ISO (#201 env info). |
Whoa, nice finding! As a temp solution, we can disable the field access via CO-RE. The field positions are very unlikely to change between different kernel versions. |
Furthermore, I add a func Copy(typ Type, transform Transformer) Type {
defer functrace.Trace()()
fmt.Printf("Copy type: %s, %+v\n", typ.TypeName(), typ)
copies := make(copier)
copies.copy(&typ, transform)
return typ
} Here is the log file: pwru.run.log. Then, dump the copying Hopefully, it can help to solve this issue. |
Fixed by #220. |
How to reproduce:
strace.log
The text was updated successfully, but these errors were encountered: