mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-07-17 16:47:50 +00:00
7daebbe469
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> |
||
|---|---|---|
| .. | ||
| uapi | ||
| compel-cpu.h | ||
| elf32-types.h | ||
| elf64-types.h | ||
| errno.h | ||
| infect-priv.h | ||
| log.h | ||
| piegen.h | ||
| ptrace.h | ||
| rpc-pie-priv.h | ||
| shmem.h | ||