search for: pvlock_type

v1->v2: - Make pv_spinlock_type a bit mask for easier checking. - Add patch 2 to deprecate xen_nopvspin v1 - https://lkml.org/lkml/2017/11/1/381 Patch 1 adds a new pvlock_type parameter for the administrators to specify the type of lock to be used in a para-virtualized kernel. Patch 2 deprecates Xen's xen_nopvspin parameter as it is no longer needed. Waiman Long (2): x86/paravirt: Add kernel parameter to choose paravirt lock type x86/xen: Deprecate xen_nopvspin...

v1->v2: - Make pv_spinlock_type a bit mask for easier checking. - Add patch 2 to deprecate xen_nopvspin v1 - https://lkml.org/lkml/2017/11/1/381 Patch 1 adds a new pvlock_type parameter for the administrators to specify the type of lock to be used in a para-virtualized kernel. Patch 2 deprecates Xen's xen_nopvspin parameter as it is no longer needed. Waiman Long (2): x86/paravirt: Add kernel parameter to choose paravirt lock type x86/xen: Deprecate xen_nopvspin...

...best lock type. >> >> The hypervisor paravirt spinlock code will override this new parameter >> in determining if pvqspinlock should be used. The parameter, however, >> will override Xen's xen_nopvspin in term of disabling unfair lock. > Hmm, I'm not sure we need pvlock_type _and_ xen_nopvspin. What do others > think? I don't think we need xen_nopvspin, but I don't want to remove that without agreement from the community. >> DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key); >> >> void __init native_pv_lock_init(void) >> { >> - i...

...best lock type. >> >> The hypervisor paravirt spinlock code will override this new parameter >> in determining if pvqspinlock should be used. The parameter, however, >> will override Xen's xen_nopvspin in term of disabling unfair lock. > Hmm, I'm not sure we need pvlock_type _and_ xen_nopvspin. What do others > think? I don't think we need xen_nopvspin, but I don't want to remove that without agreement from the community. >> DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key); >> >> void __init native_pv_lock_init(void) >> { >> - i...

...txt b/Documentation/admin-guide/kernel-parameters.txt index f7df49d..c98d9c7 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3275,6 +3275,13 @@ [KNL] Number of legacy pty's. Overwrites compiled-in default number. + pvlock_type= [X86,PV_OPS] + Specify the paravirt spinlock type to be used. + Options are: + queued - native queued spinlock + pv - paravirt queued spinlock + unfair - simple TATAS unfair lock + quiet [KNL] Disable most log messages r128= [HW,DRM] diff --git a/arch/x86/include/asm/paravirt...

...txt b/Documentation/admin-guide/kernel-parameters.txt index f7df49d..c98d9c7 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3275,6 +3275,13 @@ [KNL] Number of legacy pty's. Overwrites compiled-in default number. + pvlock_type= [X86,PV_OPS] + Specify the paravirt spinlock type to be used. + Options are: + queued - native queued spinlock + pv - paravirt queued spinlock + unfair - simple TATAS unfair lock + quiet [KNL] Disable most log messages r128= [HW,DRM] diff --git a/arch/x86/include/asm/paravirt...

...gorithm to pick the best lock type. > > The hypervisor paravirt spinlock code will override this new parameter > in determining if pvqspinlock should be used. The parameter, however, > will override Xen's xen_nopvspin in term of disabling unfair lock. Hmm, I'm not sure we need pvlock_type _and_ xen_nopvspin. What do others think? > > Signed-off-by: Waiman Long <longman at redhat.com> > --- > Documentation/admin-guide/kernel-parameters.txt | 7 +++++ > arch/x86/include/asm/paravirt.h | 9 ++++++ > arch/x86/kernel/kvm.c...

With the new pvlock_type kernel parameter, xen_nopvspin is no longer needed. This patch deprecates the xen_nopvspin parameter by removing its documentation and treating it as an alias of "pvlock_type=queued". Signed-off-by: Waiman Long <longman at redhat.com> --- Documentation/admin-guide/kernel-parameter...

On 11/01/2017 04:58 PM, Waiman Long wrote: > +/* TODO: To be removed in a future kernel version */ > static __init int xen_parse_nopvspin(char *arg) > { > - xen_pvspin = false; > + pr_warn("xen_nopvspin is deprecated, replace it with \"pvlock_type=queued\"!\n"); > + if (!pv_spinlock_type) > + pv_spinlock_type = locktype_queued; Since we currently end up using unfair locks and because you are deprecating xen_nopvspin I wonder whether it would be better to set this to locktype_unfair so that current behavior doesn't chang...

On 11/01/2017 04:58 PM, Waiman Long wrote: > +/* TODO: To be removed in a future kernel version */ > static __init int xen_parse_nopvspin(char *arg) > { > - xen_pvspin = false; > + pr_warn("xen_nopvspin is deprecated, replace it with \"pvlock_type=queued\"!\n"); > + if (!pv_spinlock_type) > + pv_spinlock_type = locktype_queued; Since we currently end up using unfair locks and because you are deprecating xen_nopvspin I wonder whether it would be better to set this to locktype_unfair so that current behavior doesn't chang...

...;>> >>> The hypervisor paravirt spinlock code will override this new parameter >>> in determining if pvqspinlock should be used. The parameter, however, >>> will override Xen's xen_nopvspin in term of disabling unfair lock. >> Hmm, I'm not sure we need pvlock_type _and_ xen_nopvspin. What do others >> think? > I don't think we need xen_nopvspin, but I don't want to remove that > without agreement from the community. I also don't think xen_nopvspin will be needed after pvlock_type is introduced. -boris

...vsky wrote: > On 11/01/2017 04:58 PM, Waiman Long wrote: >> +/* TODO: To be removed in a future kernel version */ >> static __init int xen_parse_nopvspin(char *arg) >> { >> - xen_pvspin = false; >> + pr_warn("xen_nopvspin is deprecated, replace it with \"pvlock_type=queued\"!\n"); >> + if (!pv_spinlock_type) >> + pv_spinlock_type = locktype_queued; > Since we currently end up using unfair locks and because you are > deprecating xen_nopvspin I wonder whether it would be better to set this > to locktype_unfair so that current beha...