> > > On 03/12/2014 13:12, David Hildenbrand wrote: > >> This series improves yielding on architectures that cannot disable > >> preemption > >> while entering the guest and makes the creating thread of a VCPU the owning > >> thread and therefore the yield target when yielding to that VCPU. > >> > >> We should focus on the case creating thread == executing thread and > >> therefore > >> remove the complicated handling of PIDs involving synchronize_rcus. > >> > >> This way we can speed up the creation of VCPUs and directly yield to the > >> executing vcpu threads. > >> > >> Please note that - in theory - all VCPU ioctls should be triggered from > >> the same > >> VCPU thread, so changing threads is not a scenario we should optimize. > >> > >> > >> David Hildenbrand (2): > >> KVM: don't check for PF_VCPU when yielding > >> KVM: thread creating a vcpu is the owner of that vcpu > >> > >> include/linux/kvm_host.h | 1 + > >> virt/kvm/kvm_main.c | 22 ++-------------------- > >> 2 files changed, 3 insertions(+), 20 deletions(-) > >> > > > > Hi Paolo, > > > > would be good if you could have a look at these patches. > > Sure. > > I think patch 1 is fine and I am applying it. For patch 2, what about > moving the ->pid assignment in the KVM_RUN case of kvm_vcpu_ioctl?
Thanks Paolo! Well, do we have any known user that relies on this thread-switching in case of KVM_RUN? If yes, I am totally with you. If not I'd prefer to get this code completely out, as it contains some unnecessary complexity. And maintaining such code that already had a couple of bugs in it without any benefit doesn't make much sense. What do you think? David > > Paolo > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
