Re: [PATCH 0/3] Introduce new vcpu ioctls KVM_(GET|SET)_MANY_REGS

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

 



On 2020-11-20 12:56, darkhan@xxxxxxxxxx wrote:
From: Darkhan Mukashov <darkhan@xxxxxxxxxx>

The ultimate goal is to introduce new vcpu ioctls KVM_(GET|SET)_MANY_REGS. To introduce these ioctls, implementations of KVM_(GET|SET)_ONE_REG have to be refactored. Specifically, KVM_(GET|SET)_ONE_REG should be handled in
a generic kvm_vcpu_ioctl function.

New KVM APIs KVM_(GET|SET)_MANY_REGS make it possible to bulk read/write
vCPU registers at one ioctl call. These ioctls can be very useful when
vCPU state serialization/deserialization is required (e.g. live update of
kvm, live migration of guests), hence all registers have to be
saved/restored. KVM_(GET|SET)_MANY_REGS will help avoid performance
overhead associated with syscall (ioctl in our case) handling. Tests
conducted on AWS Graviton2 Processors (64-bit ARM Neoverse cores) show
that average save/restore time of all vCPU registers can be optimized
~3.5 times per vCPU with new ioctls. Test results can be found in Table 1.
+---------+-------------+---------------+
|         | kvm_one_reg | kvm_many_regs |
+---------+-------------+---------------+
| get all |   123 usec  |    33 usec    |
+---------+-------------+---------------+
| set all |   120 usec  |    36 usec    |
+---------+-------------+---------------+
	Table 1. Test results

I have asked in private last week, and didn't get a satisfying answer:

We are talking about 90us over the time taken by enough state to be
transferred to the target so that it can be restarted. What proportion
does this represent? I'd expect userspace to do this from the vcpu
thread, and thus to be able to do everything in parallel, in which case
the gain doesn't scale with the number of vcpu.

One of the reasons for me being reluctant is that the userspace API
breaks extremely often, and that you are now adding yet another one
that can be used concurrently with the existing one.

So I would really like to see the whole picture, and not just this
very narrow "make it faster" approach. I also want to understand
why this is a "MANY" approach, and not "ALL".

Thanks,

        M.
--
Jazz is not dead. It just smells funny...



[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