On 12/11/2024 05:50, Andrii Nakryiko wrote:
On Fri, Nov 8, 2024 at 4:42 PM Vadim Fedorenko <vadfed@xxxxxxxx> wrote:
New kfunc to return ARCH-specific timecounter. For x86 BPF JIT converts
it into rdtsc ordered call. Other architectures will get JIT
implementation too if supported. The fallback is to
__arch_get_hw_counter().
Signed-off-by: Vadim Fedorenko <vadfed@xxxxxxxx>
---
nit: please add cover letter for the next revision, multi-patch sets
generally should come with a cover letter, unless it's some set of
trivial and mostly independent patches. Anyways...
Yeah, sure. This series has grown from the first small version...
I haven't yet looked through the code (yet), but I was curious to
benchmark the perf benefit, so that's what I did for fun this evening.
(!!!) BTW, a complete aside, but I think it's interesting. It turned
out that using bpf_test_prog_run() scales *VERY POORLY* with large
number of CPUs, because we start spending tons of time in
fdget()/fdput(), so I initially got pretty unscalable results,
profiled a bit, and then switched to just doing
syscall(syscall(__NR_getpgid); + SEC("raw_tp/sys_enter")). Anyways,
the point is that microbenchmarking is tricky and we need to improve
our existing bench setup for some benchmarks. Anyways, getting back to
the main topic.
I wrote a quick two benchmarks testing what I see as intended use case
for these kfuncs (batching amortizes the cost of triggering BPF
program, batch_iters = 500 in my case):
SEC("?raw_tp/sys_enter")
int trigger_driver_ktime(void *ctx)
{
volatile __u64 total = 0;
int i;
for (i = 0; i < batch_iters; i++) {
__u64 start, end;
start = bpf_ktime_get_ns();
end = bpf_ktime_get_ns();
total += end - start;
}
inc_counter_batch(batch_iters);
return 0;
}
extern __u64 bpf_get_cpu_cycles(void) __weak __ksym;
extern __u64 bpf_cpu_cycles_to_ns(__u64 cycles) __weak __ksym;
SEC("?raw_tp/sys_enter")
int trigger_driver_cycles(void *ctx)
{
volatile __u64 total = 0;
int i;
for (i = 0; i < batch_iters; i++) {
__u64 start, end;
start = bpf_get_cpu_cycles();
end = bpf_get_cpu_cycles();
total += bpf_cpu_cycles_to_ns(end - start);
}
inc_counter_batch(batch_iters);
return 0;
}
And here's what I got across multiple numbers of parallel CPUs on our
production host.
# ./bench_timing.sh
ktime ( 1 cpus): 32.286 ± 0.309M/s ( 32.286M/s/cpu)
ktime ( 2 cpus): 63.021 ± 0.538M/s ( 31.511M/s/cpu)
ktime ( 3 cpus): 94.211 ± 0.686M/s ( 31.404M/s/cpu)
ktime ( 4 cpus): 124.757 ± 0.691M/s ( 31.189M/s/cpu)
ktime ( 5 cpus): 154.855 ± 0.693M/s ( 30.971M/s/cpu)
ktime ( 6 cpus): 185.551 ± 2.304M/s ( 30.925M/s/cpu)
ktime ( 7 cpus): 211.117 ± 4.755M/s ( 30.160M/s/cpu)
ktime ( 8 cpus): 236.454 ± 0.226M/s ( 29.557M/s/cpu)
ktime (10 cpus): 295.526 ± 0.126M/s ( 29.553M/s/cpu)
ktime (12 cpus): 322.282 ± 0.153M/s ( 26.857M/s/cpu)
ktime (14 cpus): 375.347 ± 0.087M/s ( 26.811M/s/cpu)
ktime (16 cpus): 399.813 ± 0.181M/s ( 24.988M/s/cpu)
ktime (24 cpus): 617.675 ± 7.053M/s ( 25.736M/s/cpu)
ktime (32 cpus): 819.695 ± 0.231M/s ( 25.615M/s/cpu)
ktime (40 cpus): 996.264 ± 0.290M/s ( 24.907M/s/cpu)
ktime (48 cpus): 1180.201 ± 0.160M/s ( 24.588M/s/cpu)
ktime (56 cpus): 1321.084 ± 0.099M/s ( 23.591M/s/cpu)
ktime (64 cpus): 1482.061 ± 0.121M/s ( 23.157M/s/cpu)
ktime (72 cpus): 1666.540 ± 0.460M/s ( 23.146M/s/cpu)
ktime (80 cpus): 1851.419 ± 0.439M/s ( 23.143M/s/cpu)
cycles ( 1 cpus): 45.815 ± 0.018M/s ( 45.815M/s/cpu)
cycles ( 2 cpus): 86.706 ± 0.068M/s ( 43.353M/s/cpu)
cycles ( 3 cpus): 129.899 ± 0.101M/s ( 43.300M/s/cpu)
cycles ( 4 cpus): 168.435 ± 0.073M/s ( 42.109M/s/cpu)
cycles ( 5 cpus): 210.520 ± 0.164M/s ( 42.104M/s/cpu)
cycles ( 6 cpus): 252.596 ± 0.050M/s ( 42.099M/s/cpu)
cycles ( 7 cpus): 294.356 ± 0.159M/s ( 42.051M/s/cpu)
cycles ( 8 cpus): 317.167 ± 0.163M/s ( 39.646M/s/cpu)
cycles (10 cpus): 396.141 ± 0.208M/s ( 39.614M/s/cpu)
cycles (12 cpus): 431.938 ± 0.511M/s ( 35.995M/s/cpu)
cycles (14 cpus): 503.055 ± 0.070M/s ( 35.932M/s/cpu)
cycles (16 cpus): 534.261 ± 0.107M/s ( 33.391M/s/cpu)
cycles (24 cpus): 836.838 ± 0.141M/s ( 34.868M/s/cpu)
cycles (32 cpus): 1099.689 ± 0.314M/s ( 34.365M/s/cpu)
cycles (40 cpus): 1336.573 ± 0.015M/s ( 33.414M/s/cpu)
cycles (48 cpus): 1571.734 ± 11.151M/s ( 32.744M/s/cpu)
cycles (56 cpus): 1819.242 ± 4.627M/s ( 32.486M/s/cpu)
cycles (64 cpus): 2046.285 ± 5.169M/s ( 31.973M/s/cpu)
cycles (72 cpus): 2287.683 ± 0.787M/s ( 31.773M/s/cpu)
cycles (80 cpus): 2505.414 ± 0.626M/s ( 31.318M/s/cpu)
So, from about +42% on a single CPU, to +36% at 80 CPUs. Not that bad.
Scalability-wise, we still see some drop off in performance, but
believe me, with bpf_prog_test_run() it was so much worse :) I also
verified that now we spend cycles almost exclusively inside the BPF
program (so presumably in those benchmarked kfuncs).
Am I right that the numbers show how many iterations were done during
the very same amount of time? It would be also great to understand if
we get more precise measurements - just in case you have your tests
ready...
