On Tue, Nov 15, 2022 at 05:32:57PM +0000, Colton Lewis wrote:
> Collect memory access latency measured in clock cycles.
>
> This introduces a dependency on the timers for ARM and x86. No other
> architectures are implemented and their samples will all be 0.
>
> Because keeping all samples is impractical due to the space required
> in some cases (pooled memory w/ 64 vcpus would be 64 GB/vcpu * 64
> vcpus * 250,000 samples/GB * 8 bytes/sample ~ 8 Gb extra memory just
> for samples), resevior sampling is used to only keep a small number of
nit: reservoir
> samples per vcpu (1000 samples in this patch).
Didn't see this before my previous comment. But, I guess it still
applies: isn't it possible to know the number of events to store? to
avoid the "100" obtained via trial and error.
>
> Resevoir sampling means despite keeping only a small number of
> samples, each sample has an equal chance of making it to the
> resevoir. Simple proofs of this can be found online. This makes the
> resevoir a good representation of the distribution of samples and
reservoir
> enables calculation of reasonably accurate percentiles.
>
> All samples are stored in a statically allocated flat array for ease
> of combining them later. Samples are stored at an offset in this array
> calculated by the vcpu index (so vcpu 5 sample 10 would be stored at
> address sample_times + 5 * vcpu_idx + 10).
>
> Signed-off-by: Colton Lewis <coltonlewis@xxxxxxxxxx>
> ---
> .../selftests/kvm/lib/perf_test_util.c | 34 +++++++++++++++++--
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/lib/perf_test_util.c b/tools/testing/selftests/kvm/lib/perf_test_util.c
> index a48904b64e19..0311da76bae0 100644
> --- a/tools/testing/selftests/kvm/lib/perf_test_util.c
> +++ b/tools/testing/selftests/kvm/lib/perf_test_util.c
> @@ -4,6 +4,9 @@
> */
> #include <inttypes.h>
>
> +#if defined(__aarch64__)
> +#include "aarch64/arch_timer.h"
> +#endif
> #include "kvm_util.h"
> #include "perf_test_util.h"
> #include "processor.h"
> @@ -44,6 +47,18 @@ static struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
> /* Store all samples in a flat array so they can be easily sorted later. */
> uint64_t latency_samples[SAMPLE_CAPACITY];
>
> +static uint64_t perf_test_timer_read(void)
> +{
> +#if defined(__aarch64__)
> + return timer_get_cntct(VIRTUAL);
> +#elif defined(__x86_64__)
> + return rdtsc();
> +#else
> +#warn __func__ " is not implemented for this architecture, will return 0"
> + return 0;
> +#endif
> +}
> +
> /*
> * Continuously write to the first 8 bytes of each page in the
> * specified region.
> @@ -59,6 +74,10 @@ void perf_test_guest_code(uint32_t vcpu_idx)
> int i;
> struct guest_random_state rand_state =
> new_guest_random_state(pta->random_seed + vcpu_idx);
> + uint64_t *latency_samples_offset = latency_samples + SAMPLES_PER_VCPU * vcpu_idx;
> + uint64_t count_before;
> + uint64_t count_after;
> + uint32_t maybe_sample;
>
> gva = vcpu_args->gva;
> pages = vcpu_args->pages;
> @@ -75,10 +94,21 @@ void perf_test_guest_code(uint32_t vcpu_idx)
>
> addr = gva + (page * pta->guest_page_size);
>
> - if (guest_random_u32(&rand_state) % 100 < pta->write_percent)
> + if (guest_random_u32(&rand_state) % 100 < pta->write_percent) {
> + count_before = perf_test_timer_read();
> *(uint64_t *)addr = 0x0123456789ABCDEF;
> - else
> + count_after = perf_test_timer_read();
> + } else {
> + count_before = perf_test_timer_read();
> READ_ONCE(*(uint64_t *)addr);
> + count_after = perf_test_timer_read();
"count_before ... ACCESS count_after" could be moved to some macro,
e.g.,:
t = MEASURE(READ_ONCE(*(uint64_t *)addr));
> + }
> +
> + maybe_sample = guest_random_u32(&rand_state) % (i + 1);
> + if (i < SAMPLES_PER_VCPU)
> + latency_samples_offset[i] = count_after - count_before;
> + else if (maybe_sample < SAMPLES_PER_VCPU)
> + latency_samples_offset[maybe_sample] = count_after - count_before;
I would prefer these reservoir sampling details to be in a helper,
e.g.,:
reservoir_sample_record(t, i);
> }
>
> GUEST_SYNC(1);
> --
> 2.38.1.431.g37b22c650d-goog
>
