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> |
||
|---|---|---|
| .. | ||
| _run_ct | ||
| crit.sh | ||
| criu-btrfs.sh | ||
| criu-by-id.sh | ||
| criu-compat-mounts.sh | ||
| criu-dedup.sh | ||
| criu-dump.sh | ||
| criu-fault.sh | ||
| criu-fcg.sh | ||
| criu-groups.sh | ||
| criu-inhfd.sh | ||
| criu-iter.sh | ||
| criu-join-ns.sh | ||
| criu-lazy-common.sh | ||
| criu-lazy-migration.pipeline | ||
| criu-lazy-migration.sh | ||
| criu-lazy-pages.sh | ||
| criu-lib.sh | ||
| criu-other.sh | ||
| criu-overlay.sh | ||
| criu-pre-dump.sh | ||
| criu-remote-lazy-pages.sh | ||
| criu-sibling.sh | ||
| criu-snap.sh | ||
| criu-stop.sh | ||
| criu-user.sh | ||
| criu.sh | ||
| run_ct | ||