[byrnedj]

Stacked on #38 (dtoctl) and #41 (stats). Only the last commit, dtoctl: add --stats-run to measure the speedup from DSA, is new here. I'll rebase once those are merged.

dtoctl --stats-run answers two questions: how much faster is a program with DSA, and how much faster could it be? It runs the program CPU-only (DTO_USESTDC_CALLS=1) and then with DSA, collecting #41's JSON stats from each run. dto-stats-report then compares the runs using Amdahl's law. With --perf, it also profiles one run each way and shows where the CPU time went.

sudo dtoctl -w busypoll --stats-run=app-stats --repeat=3 --perf ./app 1 20000 262144 65536 20000

DTO stats run: app-stats
  command: ./app 1 20000 262144 65536 20000
  settings: DTO_WAIT_METHOD=busypoll
  timed runs: 3 CPU-only, 3 with DSA (medians)
  DTO in the DSA run: 1 WQs, wait busypoll, min_bytes 65536, cpu_size_fraction 0.5 (auto-adjusted)

                                     CPU only       with DSA   speedup
  wall time                         972.66 ms         1.55 s     0.63x
  CPU time (user+sys)               968.31 ms         1.54 s     0.63x
    in mem* calls                   304.86 ms      794.05 ms     0.38x
    outside mem* calls              663.45 ms      747.81 ms     0.89x
  wall time, min-max          972.24-973.64 ms    1.26-1.58 s

  Amdahl's law
    f, share of CPU time in mem* calls (CPU-only)     31.5%
    s, mem* speedup with DSA (time per byte)          0.38x
    predicted speedup, 1 / ((1 - f) + f / s)          0.66x
    measured speedup, wall time                       0.63x
    limit if mem* took no time, 1 / (1 - f)           1.46x

  per operation       calls       bytes   avg size   CPU only   with DSA  speedup  on DSA       f
  memcpy             20.00k     4.9 GiB  256.0 KiB  115.50 ms  266.45 ms    0.43x  100.0%   11.9%
  memset             20.00k     4.9 GiB  256.0 KiB   96.36 ms   83.32 ms    1.16x  100.0%   10.0%
  memcmp             20.00k     4.9 GiB  256.0 KiB   93.00 ms  444.27 ms    0.21x  100.0%    9.6%
    (on DSA: share of the bytes in calls sent to DSA, of which the CPU does cpu_size_fraction;
     f: share of the CPU-only run's CPU time)
    calls DSA left to the CPU, per run: page fault 1, retry 0, other 0

  by size (most time)       calls   CPU only   with DSA  speedup  on DSA
  256K-320K                60.00k    5.08 us   13.23 us    0.38x  100.0%
    (average time per call; on DSA: share of calls sent to DSA)

  profile (perf, % of CPU time)        CPU only   with DSA
    memcpy/memmove                        13.0%      12.2%
    memset                                10.0%       1.6%
    memcmp                                10.2%       0.0%
    CRC                                   14.6%      11.7%
    DTO library                            0.0%      34.4%
    libc, unknown function                 0.0%       0.1%
    other user code                       51.5%      39.6%
    other kernel code                      0.7%       0.5%

  note: mem* calls that went to DSA were slower than on the CPU at every size this program used
  note: 15% of the CPU-only run is CRC code: DSA can compute CRC32C, but DTO doesn't intercept CRC functions, so offloading it needs an explicit call

This is gnr-qual1 with one DSA (wq0.0). The test program is single-threaded: it copies, sets and compares 256 KiB buffers that stay in cache, computes a software CRC32C, and does other work. The CPU-only run spent f = 31.5% of its CPU time in mem* calls, and those calls ran at s = 0.38x with DSA. Amdahl's law therefore predicts 0.66x, and the measured speedup was 0.63x. The remaining gap shows up on its own row: time outside mem* calls went from 663 to 748 ms. The profile shows the cost of DSA here: 34% of the DSA run's CPU time is DTO busy-polling.

What it does

• dtoctl creates DIR, which must be new or empty; the default is dto-stats-<date>-<time>. It runs the program N times each way (--repeat), alternating the two modes so that drift affects both. For each run it records wall time, user+sys CPU time (wait4, so children are included) and the exit status in runs.jsonl, then runs dto-stats-report DIR.
  • Ctrl-C and Ctrl-\ go to the program, as with system(). A run that fails stops the rest, and dtoctl exits with its status.
  • --dry-run prints the plan without running anything.
• --perf[=PERF] adds one more run each way under PERF record -e cpu-clock -F 999.
  • cpu-clock needs no hardware counters. On gnr-qual1's 7.2 kernel, cycles gave about 10 samples a run.
  • perf runs dtoctl again (perf record -- dtoctl -l LIB -- prog), so DTO is preloaded into the program but not into perf.
• dto-stats-report is Python 3 using only the standard library; --json prints the numbers instead of the tables. It:
  • sums the stats of every process a run started and takes medians over the runs;
  • compares speed per byte, so a benchmark that runs for a fixed time still compares correctly;
  • lists each operation and the sizes with the most time.
• The report's notes cover:
  • no call reaching DSA, with the reason: no usable WQ (stdc_only at exit), or every call below min_bytes;
  • runs that did different amounts of work;
  • sizes where DSA lost, and a DTO_MIN_BYTES to try when there is a clear crossover;
  • runs that failed, or wrote no stats or no summary (a library too old for JSON stats, a static binary, a program that leaves with _exit() as dash does);
  • from the profile: mem* time DTO didn't intercept, CRC time DSA could take, and kernel copies.
• libc without symbols. Ubuntu's libc has no .symtab, so perf shows __memmove_avx512_unaligned_erms as a bare address. On the machine that made the profile, the report uses dlsym in its own process to find which memcpy/memset/memcmp implementations this CPU uses. It then places samples by address, but only after checking the profile's libc has the same build ID. Without this, the libc rows of the profile above would be unnamed.
• New options --stats-format and --stats-interval set DTO_STATS_FORMAT and DTO_STATS_INTERVAL_MS.

Limits

• Amdahl's estimate uses CPU time, so it assumes the program keeps its CPUs busy. A program that waits for I/O gains less in wall time; the README and man page say so.
• DTO writes stats files readable by their owner only (as on main), so results from a sudo run need sudo dto-stats-report. The report says this instead of failing with a traceback.

Testing

• ctest -R "dtoctl|stats|functional" passes:
  • locally on RHEL 8 (glibc 2.28);
  • on gnr-qual1 (Ubuntu 24.04, glibc 2.39), as a user (CPU fallback) and as root with dsa0.
• tests/test_dtoctl.sh checks:
  • the new options and the conflicting combinations;
  • the --dry-run plan;
  • a real stats run of a shell command: each run's environment, runs.jsonl, the saved stats and the report;
  • that a failing run stops the stats run with its status, and that a directory with results in it is refused.
• tests/test_stats_report.py (new stats-report ctest; needs neither DSA nor perf) checks:
  • the report's arithmetic on made-up runs with known answers: f, s, predicted, limit, medians, per-op and per-size numbers, and the notes;
  • sorting of made-up perf lines into categories;
  • finding memmove/memset/memcmp by address in the local libc, which passes on both glibc 2.28 and 2.39.
• By hand on gnr-qual1:
  • the full run above with DSA and perf;
  • SIGINT to the process group (the program dies, dtoctl exits 130 after recording the signal);
  • a program that forks (both processes counted);
  • a run against an older installed libdto (the report says it is too old for JSON stats).

Running a stats run on RHEL 8 turned up a bug in #41: libdto wasn't linked with pthread. The fix is now on #41 (stats: link libdto with pthread) and included here.