On 08/21/2014 09:38 PM, Radim Krčmář wrote:
ple_window is updated on every vmentry, so there is no reason to have it read-only anymore. ple_window* weren't writable to prevent runtime overflow races; they are prevented by a seqlock.Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- arch/x86/kvm/vmx.c | 46 +++++++++++++++++++++++++++++++++++++--------- 1 file changed, 37 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 273cbd5..1318232 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -132,24 +132,29 @@ module_param(nested, bool, S_IRUGO); #define KVM_VMX_DEFAULT_PLE_WINDOW_MAX \ INT_MAX / KVM_VMX_DEFAULT_PLE_WINDOW_GROW +static struct kernel_param_ops param_ops_ple_int; +#define param_check_ple_int(name, p) __param_check(name, p, int) + +static DEFINE_SEQLOCK(ple_window_seqlock); + static int ple_gap = KVM_VMX_DEFAULT_PLE_GAP; module_param(ple_gap, int, S_IRUGO); static int ple_window = KVM_VMX_DEFAULT_PLE_WINDOW; -module_param(ple_window, int, S_IRUGO); +module_param(ple_window, ple_int, S_IRUGO | S_IWUSR); /* Default doubles per-vcpu window every exit. */ static int ple_window_grow = KVM_VMX_DEFAULT_PLE_WINDOW_GROW; -module_param(ple_window_grow, int, S_IRUGO); +module_param(ple_window_grow, ple_int, S_IRUGO | S_IWUSR); /* Default resets per-vcpu window every exit to ple_window. */ static int ple_window_shrink = KVM_VMX_DEFAULT_PLE_WINDOW_SHRINK; -module_param(ple_window_shrink, int, S_IRUGO); +module_param(ple_window_shrink, int, S_IRUGO | S_IWUSR); /* Default is to compute the maximum so we can never overflow. */ static int ple_window_actual_max = KVM_VMX_DEFAULT_PLE_WINDOW_MAX; static int ple_window_max = KVM_VMX_DEFAULT_PLE_WINDOW_MAX; -module_param(ple_window_max, int, S_IRUGO); +module_param(ple_window_max, ple_int, S_IRUGO | S_IWUSR);
Positive thing about able to change default grow/shrink value is the flexibility of tuning ple window to different workloads and different number of cpus. But is it that a value of shrink = 1 and grow > 1 is problematic ? (running a undercommit workload and then overcommit workload) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
