search for: kvm_hibern

...t unfair locks performance in undercommit cases. > (overcommit case is expected to perform well) > > But I am seeing hang in overcommit cases. Gdb showed that many vcpus > are halted and there was no progress. Suspecting the problem /race with > halting, I removed the halt() part of kvm_hibernate(). I am yet to > take a closer look at the code on halt() related changes. It seems like there may still be race conditions where the current code is not handling correctly. I will look into that to see where the problem is. BTW, what test do you use to produce the hang condition? >...

...t unfair locks performance in undercommit cases. > (overcommit case is expected to perform well) > > But I am seeing hang in overcommit cases. Gdb showed that many vcpus > are halted and there was no progress. Suspecting the problem /race with > halting, I removed the halt() part of kvm_hibernate(). I am yet to > take a closer look at the code on halt() related changes. It seems like there may still be race conditions where the current code is not handling correctly. I will look into that to see where the problem is. BTW, what test do you use to produce the hang condition? >...

Il 12/03/2014 19:54, Waiman Long ha scritto: > @@ -807,8 +889,13 @@ void __init kvm_spinlock_init(void) > if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) > return; > > +#ifdef CONFIG_QUEUE_SPINLOCK > + pv_lock_ops.kick_cpu = kvm_kick_cpu_type; > + pv_lock_ops.hibernate = kvm_hibernate; > +#else > pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(kvm_lock_spinning); > pv_lock_ops.unlock_kick = kvm_unlock_kick; > +#endif This should also disable the unfair path. Paolo

Il 12/03/2014 19:54, Waiman Long ha scritto: > @@ -807,8 +889,13 @@ void __init kvm_spinlock_init(void) > if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) > return; > > +#ifdef CONFIG_QUEUE_SPINLOCK > + pv_lock_ops.kick_cpu = kvm_kick_cpu_type; > + pv_lock_ops.hibernate = kvm_hibernate; > +#else > pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(kvm_lock_spinning); > pv_lock_ops.unlock_kick = kvm_unlock_kick; > +#endif This should also disable the unfair path. Paolo

...ype type) +{ +} + +static inline void inc_hib_stats(void) +{ + +} +#endif /* CONFIG_KVM_DEBUG_FS */ + +static void kvm_kick_cpu_type(int cpu, enum pv_kick_type type) +{ + kvm_kick_cpu(cpu); + inc_kick_stats(type); +} + +/* + * Halt the current CPU & release it back to the host + */ +static void kvm_hibernate(void) +{ + unsigned long flags; + + if (in_nmi()) + return; + + inc_hib_stats(); + /* + * Make sure an interrupt handler can't upset things in a + * partially setup state. + */ + local_irq_save(flags); + if (arch_irqs_disabled_flags(flags)) + halt(); + else + safe_halt(); + local_irq_r...

...atic inline void inc_kick_stats(void) +{ +} + +static inline void inc_hib_stats(void) +{ + +} +#endif /* CONFIG_KVM_DEBUG_FS */ + +static void kvm_kick_cpu_type(int cpu) +{ + kvm_kick_cpu(cpu); + inc_kick_stats(); +} + +/* + * Halt the current CPU & release it back to the host + */ +static void kvm_hibernate(void) +{ + unsigned long flags; + + if (in_nmi()) + return; + + inc_hib_stats(); + /* + * Make sure an interrupt handler can't upset things in a + * partially setup state. + */ + local_irq_save(flags); + if (arch_irqs_disabled_flags(flags)) + halt(); + else + safe_halt(); + local_irq_r...

...tats(void) > +{ > + > +} > +#endif /* CONFIG_KVM_DEBUG_FS */ > + > +static void kvm_kick_cpu_type(int cpu) > +{ > + kvm_kick_cpu(cpu); > + inc_kick_stats(); > +} > + > +/* > + * Halt the current CPU & release it back to the host > + */ > +static void kvm_hibernate(void) > +{ > + unsigned long flags; > + > + if (in_nmi()) > + return; > + > + inc_hib_stats(); > + /* > + * Make sure an interrupt handler can't upset things in a > + * partially setup state. > + */ > + local_irq_save(flags); > + if (arch_irqs_disab...

...tats(void) > +{ > + > +} > +#endif /* CONFIG_KVM_DEBUG_FS */ > + > +static void kvm_kick_cpu_type(int cpu) > +{ > + kvm_kick_cpu(cpu); > + inc_kick_stats(); > +} > + > +/* > + * Halt the current CPU & release it back to the host > + */ > +static void kvm_hibernate(void) > +{ > + unsigned long flags; > + > + if (in_nmi()) > + return; > + > + inc_hib_stats(); > + /* > + * Make sure an interrupt handler can't upset things in a > + * partially setup state. > + */ > + local_irq_save(flags); > + if (arch_irqs_disab...

...: >> @@ -807,8 +889,13 @@ void __init kvm_spinlock_init(void) >> if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) >> return; >> >> +#ifdef CONFIG_QUEUE_SPINLOCK >> + pv_lock_ops.kick_cpu = kvm_kick_cpu_type; >> + pv_lock_ops.hibernate = kvm_hibernate; >> +#else >> pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(kvm_lock_spinning); >> pv_lock_ops.unlock_kick = kvm_unlock_kick; >> +#endif > > This should also disable the unfair path. > > Paolo > The unfair lock uses a different jump label and does n...

...7/2014 10:08 PM, Waiman Long wrote: > On 04/07/2014 02:14 AM, Raghavendra K T wrote: [...] >> But I am seeing hang in overcommit cases. Gdb showed that many vcpus >> are halted and there was no progress. Suspecting the problem /race with >> halting, I removed the halt() part of kvm_hibernate(). I am yet to >> take a closer look at the code on halt() related changes. > > It seems like there may still be race conditions where the current code > is not handling correctly. I will look into that to see where the > problem is. BTW, what test do you use to produce the ha...

...an Long wrote: >> On 04/07/2014 02:14 AM, Raghavendra K T wrote: > [...] >>> But I am seeing hang in overcommit cases. Gdb showed that many vcpus >>> are halted and there was no progress. Suspecting the problem /race with >>> halting, I removed the halt() part of kvm_hibernate(). I am yet to >>> take a closer look at the code on halt() related changes. >> >> It seems like there may still be race conditions where the current code >> is not handling correctly. I will look into that to see where the >> problem is. BTW, what test do you u...

...an Long wrote: >> On 04/07/2014 02:14 AM, Raghavendra K T wrote: > [...] >>> But I am seeing hang in overcommit cases. Gdb showed that many vcpus >>> are halted and there was no progress. Suspecting the problem /race with >>> halting, I removed the halt() part of kvm_hibernate(). I am yet to >>> take a closer look at the code on halt() related changes. >> >> It seems like there may still be race conditions where the current code >> is not handling correctly. I will look into that to see where the >> problem is. BTW, what test do you u...

...uest. I was curious about unfair locks performance in undercommit cases. (overcommit case is expected to perform well) But I am seeing hang in overcommit cases. Gdb showed that many vcpus are halted and there was no progress. Suspecting the problem /race with halting, I removed the halt() part of kvm_hibernate(). I am yet to take a closer look at the code on halt() related changes. Patch series with that change gave around 20% improvement for dbench 2x and 30% improvement for ebizzy 2x cases. (1x has no significant loss/gain).

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

v6->v7: - Remove an atomic operation from the 2-task contending code - Shorten the names of some macros - Make the queue waiter to attempt to steal lock when unfair lock is enabled. - Remove lock holder kick from the PV code and fix a race condition - Run the unfair lock & PV code on overcommitted KVM guests to collect performance data. v5->v6: - Change the optimized

v5->v6: - Change the optimized 2-task contending code to make it fairer at the expense of a bit of performance. - Add a patch to support unfair queue spinlock for Xen. - Modify the PV qspinlock code to follow what was done in the PV ticketlock. - Add performance data for the unfair lock as well as the PV support code. v4->v5: - Move the optimized 2-task contending code to the

v5->v6: - Change the optimized 2-task contending code to make it fairer at the expense of a bit of performance. - Add a patch to support unfair queue spinlock for Xen. - Modify the PV qspinlock code to follow what was done in the PV ticketlock. - Add performance data for the unfair lock as well as the PV support code. v4->v5: - Move the optimized 2-task contending code to the

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit

N.B. Sorry for the duplicate. This patch series were resent as the original one was rejected by the vger.kernel.org list server due to long header. There is no change in content. v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit

v7->v8: - Remove one unneeded atomic operation from the slowpath, thus improving performance. - Simplify some of the codes and add more comments. - Test for X86_FEATURE_HYPERVISOR CPU feature bit to enable/disable unfair lock. - Reduce unfair lock slowpath lock stealing frequency depending on its distance from the queue head. - Add performance data for IvyBridge-EX CPU.