Re: [PATCH 2/2] KVM: arm64: selftests: Introduce get_set_regs_perf test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 17 Feb 2022 04:52:10 +0000,
Oliver Upton <oupton@xxxxxxxxxx> wrote:
> 
> Hi Reiji,
> 
> First off, thanks for looking into this! Seems like a very useful thing
> to test :-)
> 
> On Wed, Feb 16, 2022 at 07:49:47PM -0800, Reiji Watanabe wrote:
> > Introduce a simple performance test of KVM_GET_ONE_REG/KVM_SET_ONE_REG
> > for registers that are returned by KVM_GET_REG_LIST. This is a pseudo
> > process of saving/restoring registers during live migration, and this
> > test quantifies the performance of the process.
> > 
> > Signed-off-by: Reiji Watanabe <reijiw@xxxxxxxxxx>
> > ---
> >  tools/testing/selftests/kvm/.gitignore        |   1 +
> >  tools/testing/selftests/kvm/Makefile          |   1 +
> >  .../selftests/kvm/aarch64/get_set_regs_perf.c | 456 ++++++++++++++++++
>

[...]

> Would it make sense to test some opt-in capabilities that expose
> additional registers (PMU, SVE, etc.)?

I think this is important. System registers are usually saved/restored
in groups, and due to the way we walk the sysreg array, timings are
unlikely to be uniform. Getting a grip on that could help restructure
the walking if required (either per-group arrays, or maybe a tree
structure).

Note that all of this could equally apply to the guest trapping (the
walk is the same).

And yes, there are a lot of commonalities with get-reg-list, so
reusing some of the existing infrastructure would be a good thing.


	M.

-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux