On Wed, 10 Mar 2021 17:11:47 +0000,
Paolo Bonzini <[email protected]> wrote:
>
> On 10/03/21 18:05, Marc Zyngier wrote:
> > On Wed, 10 Mar 2021 16:03:42 +0000,
> > Paolo Bonzini <[email protected]> wrote:
> >>
> >> On 10/03/21 16:51, Marc Zyngier wrote:
> >>>> + kvm_for_each_vcpu(j, vcpu, kvm) {
> >>>> + pdata = data + VM_STAT_COUNT;
> >>>> + for (i = 0; i < VCPU_STAT_COUNT; i++, pdata++)
> >>>> + *pdata += *((u64 *)&vcpu->stat + i);
> >>> Do you really need the in-kernel copy? Why not directly organise the
> >>> data structures in a way that would allow a bulk copy using
> >>> copy_to_user()?
> >>
> >> The result is built by summing per-vCPU counters, so that the counter
> >> updates are fast and do not require a lock. So consistency basically
> >> cannot be guaranteed.
> >
> > Sure, but I wonder whether there is scope for VM-global counters to be
> > maintained in parallel with per-vCPU counters if speed/efficiency is
> > of the essence (and this seems to be how it is sold in the cover
> > letter).
>
> Maintaining VM-global counters would require an atomic instruction and
> would suffer lots of cacheline bouncing even on architectures that
> have relaxed atomic memory operations.
Which is why we have per-cpu counters already. Making use of them
doesn't seem that outlandish.
> Speed/efficiency of retrieving statistics is important, but let's keep
> in mind that the baseline for comparison is hundreds of syscalls and
> filesystem lookups.
Having that baseline in the cover letter would be a good start, as
well as an indication of the frequency this is used at.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
