[kfence] Re-benchmark latest version before RFC

[melver]

We need to re-benchmark the latest version before sending the RFC. We need these up-to-date numbers to write the first commit message.

We might want to run other benchmarks, however, so far we've been using sysbench in https://github.com/google/kasan/issues/72, which might be good enough for now.

[melver]

If possible, it might be good to get results for both x86 + arm64 (using the current implementation that doesn't have a static pool).

For deciding if we need to further optimize arm64, we actually need arm64. It would be good to have this ready at the latest when people start commenting on the arm64 version.

[ramosian-glider]

I don't think we strictly need arm64 benchmarks for the RFC. My gut feeling is that implementing a static pool on ARM is both doable and worth it wrt performance, so we just need an arch/arm64 expert to look at the code.

[melver]

I don't think we strictly need arm64 benchmarks for the RFC.

Yes, I should have clarified that it's not a dependency.

My gut feeling is that implementing a static pool on ARM is both doable and worth it wrt performance, so we just need an arch/arm64 expert to look at the code.

That's reasonable. Here's hoping it is simple enough to do. :-)

[ramosian-glider]

Some benchmark data from running hackbench -s 4096 -l 500 -f 25 30 times (3 series of 1 preheat run + 10 benchmark runs with reboots between series):

sample_interval	slowdown, %	error (±%)
10	1.2	0.4
100	0.4	0.2
1000	0.8	0.7
10000	0.9	0.4
100000	0.5	0.3

This is an x86 QEMU with 1 CPU.

[ramosian-glider]

The benchmark is quite noisy, maybe running under taskset will be more helpful.

[ramosian-glider]

Please disregard the above data, it was measured with KASAN enabled. Without KASAN the slowdown is within the noise level for sample_interval values within [10,100000]

[melver]

RFC was sent, and at least for x86 we know where we're at. Let's close this for now.