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> |
||
|---|---|---|
| .. | ||
| compel | ||
| cuda-checkpoint | ||
| exhaustive | ||
| inhfd | ||
| javaTests | ||
| jenkins | ||
| libfault | ||
| others | ||
| pki | ||
| plugins | ||
| zdtm | ||
| .gitignore | ||
| abrt.sh | ||
| crit-recode.py | ||
| empty-netns-prep.sh | ||
| groups.desc | ||
| inhfd.desc | ||
| Makefile | ||
| pycriu | ||
| umount2.c | ||
| zdtm.desc | ||
| zdtm.py | ||
| zdtm_ct.c | ||
| zdtm_mount_cgroups | ||
| zdtm_umount_cgroups | ||