search for: pvqspinlock

On 11/01/2017 11:51 AM, Juergen Gross wrote: > On 01/11/17 16:32, Waiman Long wrote: >> Currently, there are 3 different lock types that can be chosen for >> the x86 architecture: >> >> - qspinlock >> - pvqspinlock >> - unfair lock >> >> One of the above lock types will be chosen at boot time depending on >> a number of different factors. >> >> Ideally, the hypervisors should be able to pick the best performing >> lock type for the current VM configuration. That is n...

On 11/01/2017 11:51 AM, Juergen Gross wrote: > On 01/11/17 16:32, Waiman Long wrote: >> Currently, there are 3 different lock types that can be chosen for >> the x86 architecture: >> >> - qspinlock >> - pvqspinlock >> - unfair lock >> >> One of the above lock types will be chosen at boot time depending on >> a number of different factors. >> >> Ideally, the hypervisors should be able to pick the best performing >> lock type for the current VM configuration. That is n...

Hi Peter, your commit f233f7f1581e ("locking/pvqspinlock, x86: Implement the paravirt qspinlock call patching") is in today's linux-next tree (i.e., next-20150511). The two #ifdef blocks listed below cannot be compiled at the current state since CONFIG_QUEUED_SPINLOCKS does not exist: +#if defined(CONFIG_PARAVIRT_SPINLOCKS) && defined(...

Hi Peter, your commit f233f7f1581e ("locking/pvqspinlock, x86: Implement the paravirt qspinlock call patching") is in today's linux-next tree (i.e., next-20150511). The two #ifdef blocks listed below cannot be compiled at the current state since CONFIG_QUEUED_SPINLOCKS does not exist: +#if defined(CONFIG_PARAVIRT_SPINLOCKS) && defined(...

On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote: > arch/x86/include/asm/pvqspinlock.h | 411 +++++++++++++++++++++++++++++++++ I do wonder why all this needs to live in x86.. > > +#ifdef CONFIG_QUEUE_SPINLOCK > + > +static __always_inline void pv_kick_cpu(int cpu) > +{ > + PVOP_VCALLEE1(pv_lock_ops.kick_cpu, cpu); > +} > + > +static __always_inlin...

...of the queue head CPU and the following node CPU in the queue to make sure that their CPUs will stay scheduled in. Signed-off-by: Waiman Long <Waiman.Long at hp.com> --- arch/x86/include/asm/paravirt.h | 9 ++- arch/x86/include/asm/paravirt_types.h | 12 +++ arch/x86/include/asm/pvqspinlock.h | 176 +++++++++++++++++++++++++++++++++ arch/x86/kernel/paravirt-spinlocks.c | 4 + kernel/locking/qspinlock.c | 41 +++++++- 5 files changed, 235 insertions(+), 7 deletions(-) create mode 100644 arch/x86/include/asm/pvqspinlock.h diff --git a/arch/x86/include/asm/paravirt...

...ation of disabling unlock > inlining when paravirt_spinlock is enabled. With that, I think it is > worthwhile to reduce the performance delta between the PV and non-PV > kernel on bare metal. I am sorry that the unlock call sites patching code doesn't work in a virtual guest. Your pvqspinlock patch did an unconditional patching even in a virtual guest. I added check for the paravirt_spinlocks_enabled, but it turned out that some spin_unlock() seemed to be called before paravirt_spinlocks_enabled is set. As a result, some call sites were still patched resulting in missed wake up'...

...Westmere-EP (HT on) > > Waiman Long (10): > qspinlock: A generic 4-byte queue spinlock implementation > qspinlock, x86: Enable x86-64 to use queue spinlock > qspinlock: More optimized code for smaller NR_CPUS > qspinlock: Optimized code path for 2 contending tasks > pvqspinlock, x86: Allow unfair spinlock in a PV guest > pvqspinlock: Enable lock stealing in queue lock waiters > pvqspinlock, x86: Rename paravirt_ticketlocks_enabled > pvqspinlock, x86: Add qspinlock para-virtualization support > pvqspinlock, x86: Enable qspinlock PV support for KVM >...

...gt; until someone can spend the time and effort to fix them. > > Waiman Long (8): > qspinlock: Introducing a 4-byte queue spinlock implementation > qspinlock, x86: Enable x86-64 to use queue spinlock > qspinlock, x86: Add x86 specific optimization for 2 contending tasks > pvqspinlock, x86: Allow unfair spinlock in a real PV environment > pvqspinlock, x86: Enable unfair queue spinlock in a KVM guest > pvqspinlock, x86: Rename paravirt_ticketlocks_enabled > pvqspinlock, x86: Add qspinlock para-virtualization support > pvqspinlock, x86: Enable KVM to use qspinl...

On 07/04/15 03:55, Waiman Long wrote: > This patch adds the necessary Xen specific code to allow Xen to > support the CPU halting and kicking operations needed by the queue > spinlock PV code. This basically looks the same as the version I wrote, except I think you broke it. > +static void xen_qlock_wait(u8 *byte, u8 val) > +{ > + int irq = __this_cpu_read(lock_kicker_irq);

On Thu, Apr 09, 2015 at 08:13:27PM +0200, Peter Zijlstra wrote: > On Mon, Apr 06, 2015 at 10:55:44PM -0400, Waiman Long wrote: > > +#define PV_HB_PER_LINE (SMP_CACHE_BYTES / sizeof(struct pv_hash_bucket)) > > +static struct qspinlock **pv_hash(struct qspinlock *lock, struct pv_node *node) > > +{ > > + unsigned long init_hash, hash = hash_ptr(lock, pv_lock_hash_bits);

On Wed, Apr 29, 2015 at 11:11 AM, Peter Zijlstra <peterz at infradead.org> wrote: > On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: >> In the pv_scan_next() function, the slow cmpxchg atomic operation is >> performed even if the other CPU is not even close to being halted. This >> extra cmpxchg can harm slowpath performance. >> >> This patch

On 04/29/2015 02:11 PM, Peter Zijlstra wrote: > On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: >> In the pv_scan_next() function, the slow cmpxchg atomic operation is >> performed even if the other CPU is not even close to being halted. This >> extra cmpxchg can harm slowpath performance. >> >> This patch introduces the new mayhalt flag to indicate if

On 07/04/15 03:55, Waiman Long wrote: > This patch adds the necessary Xen specific code to allow Xen to > support the CPU halting and kicking operations needed by the queue > spinlock PV code. This basically looks the same as the version I wrote, except I think you broke it. > +static void xen_qlock_wait(u8 *byte, u8 val) > +{ > + int irq = __this_cpu_read(lock_kicker_irq);

This patch adds a KVM init function to activate the unfair queue spinlock in a KVM guest when the PARAVIRT_UNFAIR_LOCKS kernel config option is selected. Signed-off-by: Waiman Long <Waiman.Long at hp.com> --- arch/x86/kernel/kvm.c | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 713f1b3..a489140

Il 27/02/2014 13:11, David Vrabel ha scritto: >> > This patch adds para-virtualization support to the queue spinlock code >> > by enabling the queue head to kick the lock holder CPU, if known, >> > in when the lock isn't released for a certain amount of time. It >> > also enables the mutual monitoring of the queue head CPU and the >> > following

Il 27/02/2014 15:18, David Vrabel ha scritto: > On 27/02/14 13:11, Paolo Bonzini wrote: >> Il 27/02/2014 13:11, David Vrabel ha scritto: >>>>> This patch adds para-virtualization support to the queue spinlock code >>>>> by enabling the queue head to kick the lock holder CPU, if known, >>>>> in when the lock isn't released for a certain

On Wed, Feb 26, 2014 at 10:14:25AM -0500, Waiman Long wrote: > This patch adds a KVM init function to activate the unfair queue > spinlock in a KVM guest when the PARAVIRT_UNFAIR_LOCKS kernel config > option is selected. > > Signed-off-by: Waiman Long <Waiman.Long at hp.com> > --- > arch/x86/kernel/kvm.c | 17 +++++++++++++++++ > 1 files changed, 17 insertions(+),

Il 27/02/2014 16:22, Raghavendra K T ha scritto: > On 02/27/2014 08:15 PM, Paolo Bonzini wrote: > [...] >>> But neither of the VCPUs being kicked here are halted -- they're either >>> running or runnable (descheduled by the hypervisor). >> >> /me actually looks at Waiman's code... >> >> Right, this is really different from pvticketlocks,

On 03/03/2014 05:55 AM, Paolo Bonzini wrote: > Il 28/02/2014 18:06, Waiman Long ha scritto: >> On 02/26/2014 12:07 PM, Konrad Rzeszutek Wilk wrote: >>> On Wed, Feb 26, 2014 at 10:14:24AM -0500, Waiman Long wrote: >>>> Locking is always an issue in a virtualized environment as the virtual >>>> CPU that is waiting on a lock may get scheduled out and hence