search for: ticketlock

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

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

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

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

...e the problem. > > > > BTW, does the halting and sending IPI mechanism work in HVM? I saw Yes. > 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

...e the problem. > > > > BTW, does the halting and sending IPI mechanism work in HVM? I saw Yes. > 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

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

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

...added to simulate a busy guest. If PV qspinlock is not enabled, unfairlock will be used automically in a guest. AIM7 XFS Disk Test (no overcommit) kernel JPM Real Time Sys Time Usr Time ----- --- --------- -------- -------- PV ticketlock 2542373 7.08 98.95 5.44 PV qspinlock 2549575 7.06 98.63 5.40 unfairlock 2616279 6.91 97.05 5.42 AIM7 XFS Disk Test (200% overcommit) kernel JPM Real Time Sys Time Usr Time -----...

...added to simulate a busy guest. If PV qspinlock is not enabled, unfairlock will be used automically in a guest. AIM7 XFS Disk Test (no overcommit) kernel JPM Real Time Sys Time Usr Time ----- --- --------- -------- -------- PV ticketlock 2542373 7.08 98.95 5.44 PV qspinlock 2549575 7.06 98.63 5.40 unfairlock 2616279 6.91 97.05 5.42 AIM7 XFS Disk Test (200% overcommit) kernel JPM Real Time Sys Time Usr Time -----...

...ism work in HVM? I saw > >>>Yes. > >>>>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. > >>The RHEL7 code has used PV ticketlock already. RHEL7 uses...

...ism work in HVM? I saw > >>>Yes. > >>>>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. > >>The RHEL7 code has used PV ticketlock already. RHEL7 uses...

...tail part > of the lock word. Secondly, pv_link_and_wait_node() will propagate the > existing head from the old to the new tail node. I dug in the code and I have some comments about it, but before I post them I was wondering if you have any plans to run any performance tests against the PV ticketlock with normal and over-committed scenarios? Looking at this with a pen and paper I see that compared to PV ticketlock for the CPUs that are contending on the queue (so they go to pv_wait_head_and_link, then progress to pv_wait_head), they go sleep twice and get woken up twice. In PV ticketlock the c...

...tail part > of the lock word. Secondly, pv_link_and_wait_node() will propagate the > existing head from the old to the new tail node. I dug in the code and I have some comments about it, but before I post them I was wondering if you have any plans to run any performance tests against the PV ticketlock with normal and over-committed scenarios? Looking at this with a pen and paper I see that compared to PV ticketlock for the CPUs that are contending on the queue (so they go to pv_wait_head_and_link, then progress to pv_wait_head), they go sleep twice and get woken up twice. In PV ticketlock the c...

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

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. The current set of patches are for Xen/x86 spinlock/KVM guest side, to be included against -tip. A separate patchset for KVM host based on kvm tree is already sent. Results: ======= setup: 32 core machine with 32 vcpu KVM guest...

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. The current set of patches are for Xen/x86 spinlock/KVM guest side, to be included against -tip. A separate patchset for KVM host based on kvm tree is already sent. Results: ======= setup: 32 core machine with 32 vcpu KVM guest...

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. The current set of patches are for Xen/x86 spinlock/KVM guest side, to be included against -tip. A separate patchset for KVM host based on kvm tree is already sent. Results: ======= setup: 32 core machine with 32 vcpu KVM guest...

...+ PV qspinlock" below means that both the unfair lock and PV spinlock configuration options were turned on. AIM7 XFS Disk Test (no overcommit) kernel JPM Real Time Sys Time Usr Time ----- --- --------- -------- -------- PV ticketlock 2489626 7.23 101.08 5.30 qspinlock 2531646 7.11 100.75 5.43 PV qspinlock 2500000 7.20 101.94 5.40 unfair qspinlock 2549575 7.06 99.81 5.35 unfair + PV qspinlock 2486188 7.24 101.55 5.51...