[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v7 06/11] x86, paravirt: Add interface to support kvm/xen vcpu preempted check
- To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- From: Pan Xinhui <xinhui@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 17 Nov 2016 13:16:30 +0800
- Cc: kvm@xxxxxxxxxxxxxxx, rkrcmar@xxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, bsingharora@xxxxxxxxx, will.deacon@xxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, paulus@xxxxxxxxx, kernellwp@xxxxxxxxx, linux-s390@xxxxxxxxxxxxxxx, dave@xxxxxxxxxxxx, mpe@xxxxxxxxxxxxxx, x86@xxxxxxxxxx, borntraeger@xxxxxxxxxx, mingo@xxxxxxxxxx, Pan Xinhui <xinhui.pan@xxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, paulmck@xxxxxxxxxxxxxxxxxx, boqun.feng@xxxxxxxxx, jgross@xxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, David.Laight@xxxxxxxxxx, xen-devel-request@xxxxxxxxxxxxxxxxxxxx, pbonzini@xxxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx
- Delivery-date: Thu, 17 Nov 2016 05:16:53 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
在 2016/11/16 18:23, Peter Zijlstra 写道:
On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote:
Hi, Peter.
I think we can avoid a function call in a simpler way. How about below
static inline bool vcpu_is_preempted(int cpu)
{
/* only set in pv case*/
if (pv_lock_ops.vcpu_is_preempted)
return pv_lock_ops.vcpu_is_preempted(cpu);
return false;
}
That is still more expensive. It needs to do an actual load and makes it
hard to predict the branch, you'd have to actually wait for the load to
complete etc.
yes, one more load in native case. I think this is acceptable as
vcpu_is_preempted is not a critical function.
however if we use pv_callee_save_regs_thunk, more unnecessary registers might
be save/resotred in pv case.
that will introduce a little overhead.
but I think I am okay with your idea. I can make another patch based on this
patchset with your suggested-by.
thanks
xinhui
Also, it generates more code.
Paravirt muck should strive to be as cheap as possible when ran on
native hardware.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
