On Thu, Jun 12, 2014 at 05:08:28PM -0400, Waiman Long wrote:
Native performance is king, try your very utmost bestest to preserve
that, paravirt is a distant second and nobody sane should care about the
virt case at all.
The patch won't affect native performance unless the kernel is built
On 06/12/2014 01:50 AM, Peter Zijlstra wrote:
On Wed, Jun 11, 2014 at 09:37:55PM -0400, Long, Wai Man wrote:
On 6/11/2014 6:54 AM, Peter Zijlstra wrote:
On Fri, May 30, 2014 at 11:43:55AM -0400, Waiman Long wrote:
Enabling this configuration feature causes a slight decrease the
performance of
On Wed, Jun 11, 2014 at 12:54:02PM +0200, Peter Zijlstra wrote:
@@ -252,6 +260,18 @@ void queue_spin_lock_slowpath(struct qspinlock *lock,
u32 val)
BUILD_BUG_ON(CONFIG_NR_CPUS = (1U _Q_TAIL_CPU_BITS));
+#ifdef CONFIG_VIRT_UNFAIR_LOCKS
+ /*
+* A simple test and set
On 6/11/2014 6:54 AM, Peter Zijlstra wrote:
On Fri, May 30, 2014 at 11:43:55AM -0400, Waiman Long wrote:
Enabling this configuration feature causes a slight decrease the
performance of an uncontended lock-unlock operation by about 1-2%
mainly due to the use of a static key. However,
On Wed, Jun 11, 2014 at 09:37:55PM -0400, Long, Wai Man wrote:
On 6/11/2014 6:54 AM, Peter Zijlstra wrote:
On Fri, May 30, 2014 at 11:43:55AM -0400, Waiman Long wrote:
Enabling this configuration feature causes a slight decrease the
performance of an uncontended lock-unlock operation by
Locking is always an issue in a virtualized environment because of 2
different types of problems:
1) Lock holder preemption
2) Lock waiter preemption
One solution to the lock waiter preemption problem is to allow unfair
lock in a virtualized environment. In this case, a new lock acquirer
can