Il 19/03/2014 04:15, Waiman Long ha scritto:
You should see the same values with the PV ticketlock. It is not clear
to me if this testing did include that variant of locks?
Yes, PV is fine. But up to this point of the series, we are concerned
about spinlock performance when running on an
On Tue, Mar 18, 2014 at 11:11:43PM -0400, Waiman Long wrote:
On 03/17/2014 03:10 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
On 03/14/2014 04:30 AM, Peter Zijlstra wrote:
On Thu, Mar 13, 2014 at 04:05:19PM -0400, Waiman Long wrote:
On
Il 19/03/2014 17:58, Waiman Long ha scritto:
Exactly. What you want is boot_cpu_has(X86_FEATURE_HYPERVISOR).
The unfair lock is to be enabled by boot time check, not just by the
presence of a configuration macro during the build process in order to
avoid using unfair lock on bare metal. Of
On 03/19/2014 06:07 AM, Paolo Bonzini wrote:
Il 19/03/2014 04:15, Waiman Long ha scritto:
You should see the same values with the PV ticketlock. It is not clear
to me if this testing did include that variant of locks?
Yes, PV is fine. But up to this point of the series, we are concerned
Il 17/03/2014 20:05, Konrad Rzeszutek Wilk ha scritto:
Measurements were done by Gleb for two guests running 2.6.32 with 16
vcpus each, on a 16-core system. One guest ran with unfair locks,
one guest ran with fair locks. Two kernel compilations (time make
And when you say fair locks are
Il 17/03/2014 19:54, Peter Zijlstra ha scritto:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
The PV ticketlock code was designed to handle lock holder preemption by
redirecting CPU resources in a preempted guest to another guest that can
better use it and then return the
On 03/17/2014 02:54 PM, Peter Zijlstra wrote:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
The PV ticketlock code was designed to handle lock holder preemption by
redirecting CPU resources in a preempted guest to another guest that can
better use it and then return the preempted
On 03/17/2014 03:10 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
On 03/14/2014 04:30 AM, Peter Zijlstra wrote:
On Thu, Mar 13, 2014 at 04:05:19PM -0400, Waiman Long wrote:
On 03/13/2014 11:15 AM, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at
On 03/18/2014 04:14 AM, Paolo Bonzini wrote:
Il 17/03/2014 20:05, Konrad Rzeszutek Wilk ha scritto:
Measurements were done by Gleb for two guests running 2.6.32 with 16
vcpus each, on a 16-core system. One guest ran with unfair locks,
one guest ran with fair locks. Two kernel compilations
On 03/14/2014 04:30 AM, Peter Zijlstra wrote:
On Thu, Mar 13, 2014 at 04:05:19PM -0400, Waiman Long wrote:
On 03/13/2014 11:15 AM, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 02:54:52PM -0400, Waiman Long wrote:
+static inline void arch_spin_lock(struct qspinlock *lock)
+{
+ if
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
The PV ticketlock code was designed to handle lock holder preemption by
redirecting CPU resources in a preempted guest to another guest that can
better use it and then return the preempted CPU back sooner.
But that's the PV code, not
On Thu, Mar 13, 2014 at 02:16:06PM +0100, Paolo Bonzini wrote:
Il 13/03/2014 11:54, David Vrabel ha scritto:
On 12/03/14 18:54, 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 block
any
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
On 03/14/2014 04:30 AM, Peter Zijlstra wrote:
On Thu, Mar 13, 2014 at 04:05:19PM -0400, Waiman Long wrote:
On 03/13/2014 11:15 AM, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 02:54:52PM -0400, Waiman Long wrote:
+static inline
On Thu, Mar 13, 2014 at 04:05:19PM -0400, Waiman Long wrote:
On 03/13/2014 11:15 AM, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 02:54:52PM -0400, Waiman Long wrote:
+static inline void arch_spin_lock(struct qspinlock *lock)
+{
+ if (static_key_false(paravirt_unfairlocks_enabled))
+
Il 14/03/2014 09:30, Peter Zijlstra ha scritto:
Take the situation of 3 (v)CPUs where cpu0 holds the lock but is
preempted. cpu1 queues, cpu2 queues. Then cpu1 gets preempted, after
which cpu0 gets back online.
The simple test-and-set lock will now let cpu2 acquire. Your queue
however will just
On 12/03/14 18:54, 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 block
any progress in lock acquisition even when the lock has been freed.
One solution to this problem is to allow unfair
Il 13/03/2014 11:54, David Vrabel ha scritto:
On 12/03/14 18:54, 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 block
any progress in lock acquisition even when the lock has been freed.
One
On Wed, Mar 12, 2014 at 02:54:52PM -0400, Waiman Long wrote:
+static inline void arch_spin_lock(struct qspinlock *lock)
+{
+ if (static_key_false(paravirt_unfairlocks_enabled))
+ queue_spin_lock_unfair(lock);
+ else
+ queue_spin_lock(lock);
+}
So I would
On 03/13/2014 06:54 AM, David Vrabel wrote:
On 12/03/14 18:54, 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 block
any progress in lock acquisition even when the lock has been freed.
One
On 03/13/2014 11:15 AM, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 02:54:52PM -0400, Waiman Long wrote:
+static inline void arch_spin_lock(struct qspinlock *lock)
+{
+ if (static_key_false(paravirt_unfairlocks_enabled))
+ queue_spin_lock_unfair(lock);
+ else
+
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 block
any progress in lock acquisition even when the lock has been freed.
One solution to this problem is to allow unfair lock in a
para-virtualized environment. In
21 matches
Mail list logo
