search for: ticketlocks

...nfairness may be particularly evident on a virtualized guest > when the host is overcommitted, but problems with fair locks are > even worse. > > In fact, RHEL/CentOS 6 already uses unfair locks if > X86_FEATURE_HYPERVISOR is set. The patch was rejected upstream in > favor of pv ticketlocks, but pv ticketlocks do not cover all > hypervisors so perhaps we could revisit that choice. > > 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 comp...

...nfairness may be particularly evident on a virtualized guest > when the host is overcommitted, but problems with fair locks are > even worse. > > In fact, RHEL/CentOS 6 already uses unfair locks if > X86_FEATURE_HYPERVISOR is set. The patch was rejected upstream in > favor of pv ticketlocks, but pv ticketlocks do not cover all > hypervisors so perhaps we could revisit that choice. > > 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 comp...

...7:04PM +0530, Raghavendra K T wrote: >> In virtualized environment there are mainly three problems >> related to spinlocks that affects performance. >> 1. LHP (lock holder preemption) >> 2. Lock Waiter Preemption (LWP) >> 3. Starvation/fairness >> >> Though Ticketlocks solve fairness problem it worsens LWP, LHP problems. Though >> pv-ticketlocks tried to address these problems we can further improve at the >> cost of relaxed fairness. The following patch tries to achieve that by grouping >> (batched) ticketlocks. > > And here I stop read...

...7:04PM +0530, Raghavendra K T wrote: >> In virtualized environment there are mainly three problems >> related to spinlocks that affects performance. >> 1. LHP (lock holder preemption) >> 2. Lock Waiter Preemption (LWP) >> 3. Starvation/fairness >> >> Though Ticketlocks solve fairness problem it worsens LWP, LHP problems. Though >> pv-ticketlocks tried to address these problems we can further improve at the >> cost of relaxed fairness. The following patch tries to achieve that by grouping >> (batched) ticketlocks. > > And here I stop read...

...n 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

...n 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

In virtualized environment there are mainly three problems related to spinlocks that affects performance. 1. LHP (lock holder preemption) 2. Lock Waiter Preemption (LWP) 3. Starvation/fairness Though Ticketlocks solve fairness problem it worsens LWP, LHP problems. Though pv-ticketlocks tried to address these problems we can further improve at the cost of relaxed fairness. The following patch tries to achieve that by grouping (batched) ticketlocks. Here we form a batch of eligible lock holders and we serv...

In virtualized environment there are mainly three problems related to spinlocks that affects performance. 1. LHP (lock holder preemption) 2. Lock Waiter Preemption (LWP) 3. Starvation/fairness Though Ticketlocks solve fairness problem it worsens LWP, LHP problems. Though pv-ticketlocks tried to address these problems we can further improve at the cost of relaxed fairness. The following patch tries to achieve that by grouping (batched) ticketlocks. Here we form a batch of eligible lock holders and we serv...

This patch adds the necessary KVM specific code to allow KVM to support the CPU halting and kicking operations needed by the queue spinlock PV code. Two KVM guests of 20 CPU cores (2 nodes) were created for performance testing in one of the following three configurations: 1) Only 1 VM is active 2) Both VMs are active and they share the same 20 physical CPUs (200% overcommit) The tests run

This patch adds the necessary KVM specific code to allow KVM to support the CPU halting and kicking operations needed by the queue spinlock PV code. Two KVM guests of 20 CPU cores (2 nodes) were created for performance testing in one of the following three configurations: 1) Only 1 VM is active 2) Both VMs are active and they share the same 20 physical CPUs (200% overcommit) The tests run

...t; >>>>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. > >>The RHEL7 code has used PV ticketlock already. RHEL7 uses a single > >>kernel for all configurations. So PV ticketlock as well as Xen and > >>KVM support was compiled in. I thin...

...t; >>>>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. > >>The RHEL7 code has used PV ticketlock already. RHEL7 uses a single > >>kernel for all configurations. So PV ticketlock as well as Xen and > >>KVM support was compiled in. I thin...

On Sun, Jun 15, 2014 at 02:47:07PM +0200, Peter Zijlstra wrote: > Add minimal paravirt support. > > The code aims for minimal impact on the native case. Woot! > > On the lock side we add one jump label (asm_goto) and 4 paravirt > callee saved calls that default to NOPs. The only effects are the > extra NOPs and some pointless MOVs to accomodate the calling > convention.

On Sun, Jun 15, 2014 at 02:47:07PM +0200, Peter Zijlstra wrote: > Add minimal paravirt support. > > The code aims for minimal impact on the native case. Woot! > > On the lock side we add one jump label (asm_goto) and 4 paravirt > callee saved calls that default to NOPs. The only effects are the > extra NOPs and some pointless MOVs to accomodate the calling > convention.

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 lock in a > para-virtualized environment. In this case, a new lock acquirer

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 lock in a > para-virtualized environment. In this case, a new lock acquirer

....org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spi...

....org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spi...

....org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spi...

This patch adds the necessary KVM specific code to allow KVM to support the CPU halting and kicking operations needed by the queue spinlock PV code. Two KVM guests of 20 CPU cores (2 nodes) were created for performance testing in one of the following three configurations: 1) Only 1 VM is active 2) Both VMs are active and they share the same 20 physical CPUs (200% overcommit) 3) Both VMs are