Thread (14 messages) 14 messages, 2 authors, 2014-10-27

Re: [PATCH v12 00/11] qspinlock: a 4-byte queue spinlock with PV support

From: Waiman Long <hidden>
Date: 2014-10-27 18:00:57
Also in: kvm, linux-arch, lkml

On 10/24/2014 04:57 AM, Peter Zijlstra wrote:
On Thu, Oct 16, 2014 at 02:10:29PM -0400, Waiman Long wrote:
quoted
v11->v12:
  - Based on PeterZ's version of the qspinlock patch
    (https://lkml.org/lkml/2014/6/15/63).
  - Incorporated many of the review comments from Konrad Wilk and
    Paolo Bonzini.
  - The pvqspinlock code is largely from my previous version with
    PeterZ's way of going from queue tail to head and his idea of
    using callee saved calls to KVM and XEN codes.
Thanks for taking the time to refresh this.. I would prefer you use a
little more of the PV techniques I outlined in my latest PV patch to
further reduce the overhead of PV enabled kernels on real hardware.

This is an important use case, because distro kernels will have to
enable PV support while their majority of installations will be on
physical hardware.

Other than that I see no reason not to move this forward.
Thanks for reviewing the patch and agree to move forward. Currently, I 
am thinking of separating out a PV and non-PV versions of the lock 
slowpath functions as shown in my previous mail. That should also 
minimize the performance impact on bare metal even more than what can be 
done with the PV techniques used in your patch while not penalizing PV 
performance.

As for the unlock function, if the site patching function can handle all 
the possible call sites of spin_unlock() without disabling function 
inlining, I will be glad to use your way of handing unlock function. 
Otherwise, I will prefer my current approach as it is simpler and more 
easy to understand as well as similar to what has been done in the pv 
ticket spinlock code.

-Longman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help