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
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 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 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
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 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
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, uncontended lock-unlock
> operation are really just
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, uncontended lock-unlock
operation are really just a
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
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
14 matches
Mail list logo
