lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 3 Apr 2014 13:23:34 -0400
From:	Konrad Rzeszutek Wilk <>
To:	Waiman Long <>
Cc:	Marcos Matsunaga <>,
	Thomas Gleixner <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>,
	Peter Zijlstra <>,,,,,,,
	Paolo Bonzini <>,
	"Paul E. McKenney" <>,
	Rik van Riel <>,
	Linus Torvalds <>,
	Raghavendra K T <>,
	David Vrabel <>,
	Oleg Nesterov <>,
	Gleb Natapov <>,
	Aswin Chandramouleeswaran <>,
	Scott J Norton <>,
	Chegu Vinod <>,
Subject: Re: [PATCH v8 00/10] qspinlock: a 4-byte queue spinlock with PV

On Wed, Apr 02, 2014 at 10:10:17PM -0400, Waiman Long wrote:
> On 04/02/2014 04:35 PM, Waiman Long wrote:
> >On 04/02/2014 10:32 AM, Konrad Rzeszutek Wilk wrote:
> >>On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote:
> >>>N.B. Sorry for the duplicate. This patch series were resent as the
> >>>      original one was rejected by the list server
> >>>      due to long header. There is no change in content.
> >>>
> >>>v7->v8:
> >>>   - Remove one unneeded atomic operation from the slowpath, thus
> >>>     improving performance.
> >>>   - Simplify some of the codes and add more comments.
> >>>   - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable
> >>>     unfair lock.
> >>>   - Reduce unfair lock slowpath lock stealing frequency depending
> >>>     on its distance from the queue head.
> >>>   - Add performance data for IvyBridge-EX CPU.
> >>FYI, your v7 patch with 32 VCPUs (on a 32 cpu socket machine) on an
> >>HVM guest under Xen after a while stops working. The workload
> >>is doing 'make -j32' on the Linux kernel.
> >>
> >>Completely unresponsive. Thoughts?
> >>
> >
> >Thank for reporting that. I haven't done that much testing on Xen.
> >My focus was in KVM. I will perform more test on Xen to see if I
> >can reproduce the problem.
> >
> BTW, does the halting and sending IPI mechanism work in HVM? I saw

> that in RHEL7, PV spinlock was explicitly disabled when in HVM mode.
> However, this piece of code isn't in upstream code. So I wonder if
> there is problem with that.

The PV ticketlock fixed it for HVM. It was disabled before because
the PV guests were using bytelocks while the HVM were using ticketlocks
and you couldnt' swap in PV bytelocks for ticketlocks during startup.

> -Longman
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists