On Wed, 10 Mar 2021 17:11:47 +0000, Paolo Bonzini pbonzini@redhat.com wrote:
On 10/03/21 18:05, Marc Zyngier wrote:
On Wed, 10 Mar 2021 16:03:42 +0000, Paolo Bonzini pbonzini@redhat.com 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.