mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-07-24 02:29:23 +00:00
2e6967ac83
Hardware breakpoints were originally intended to speed up the resume process by stopping the process at a specific point in the pie code. However, it turned out that they don't provide a significant speedup and, in some cases, can even slow it down. This is especially critical for hosts with a large number of CPUs. Hardware Breakpoint Restore Performance Benchmark ================================================== System: Linux 6.17.0-1007-gcp x86_64 CPU: INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz Virt: google CRIU: Version: 4.2 Iterations per data point: 5 Threads With BP (us) Without BP (us) Diff (%) -------- ------------ --------------- -------- >>> Benchmarking with 1 thread(s)... 1 391 326 19.9% >>> Benchmarking with 10 thread(s)... 10 1098 695 58.0% >>> Benchmarking with 50 thread(s)... 50 3772 2344 60.9% >>> Benchmarking with 100 thread(s)... 100 6740 4504 49.6% >>> Benchmarking with 500 thread(s)... 500 31382 19982 57.1% >>> Benchmarking with 1000 thread(s)... 1000 58617 40568 44.5% Notes: 'With BP' = hardware breakpoints enabled (current default) 'Without BP' = CRIU_FAULT=130 (FI_NO_BREAKPOINTS, uses PTRACE_SYSCALL) Positive diff% means breakpoints are slower Signed-off-by: Andrei Vagin <avagin@google.com> |
||
|---|---|---|
| .. | ||
| asm | ||
| common | ||
| compel | ||
| cpu.h | ||
| handle-elf.h | ||
| infect-rpc.h | ||
| infect-util.h | ||
| infect.h | ||
| ksigset.h | ||
| log.h | ||
| loglevels.h | ||
| plugins | ||
| plugins.h | ||
| ptrace.h | ||
| sigframe-common.h | ||
| task-state.h | ||