Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4808944ybv; Mon, 17 Feb 2020 06:23:23 -0800 (PST) X-Google-Smtp-Source: APXvYqxwS0DNmBiM7hlKdXvIxnRwwg1xgLGmuS4ClUws5SyBCLDn5wd7Os+vtDuwR4CBo1UL47ut X-Received: by 2002:a9d:7b51:: with SMTP id f17mr12093159oto.302.1581949403032; Mon, 17 Feb 2020 06:23:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581949402; cv=none; d=google.com; s=arc-20160816; b=JYUepbvBenCT6PJA1t967R9IBc5l7zPo/BCB8m0Zp+L9HPTvpj+5LWDW1wAWE7VQ/1 x/f/HzbqVu+qXDVRvb75AxpWFUKtCcehjZf9uPVCD2FVLRktQrj7PoO+jJrbV0HQx5cF dMNZhsanOq1N+Ue3BfvRmj48qsa6I0gA3ynGYc9aFQYMHVv7wS8WnaTaIAIFTYYQW1eR uI63FRUOVe7rjBqQwNtQAbot7VtX/bTjS4KBMoizqcM0BiWr9GwalexxpX4v7OR/3+DV pI9RbK9joTLQaQiVQsFwrLgzVp0IFmz7Z+DweCpZWyxvRxMCMNtTi3QCzVF5jP2G08+Y OkGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=X5owJ1Q5kyCcEn/wK666suwQNxuxUfzmbCXN/IZugIc=; b=C+HTFJQs5mL/ZGcERxfqleLq4U8AnOBg2OGzXYnKDW2dMBdc7N/+hQjrgOr35Y5ViD Aaky9JcTl6o/o//mrZu+WuPNpNSrv2UrwBkJExNX2P7XYXvSe51WD0Ib6rKFpcMEou5W FLBsZC6appkxTnABiN47TZtjVleIBZo263tP72kSp41gTyxElfkCOZxjuDBhWRrWPYSn LsMvRI+1bGN7ZciDhUrOPXVlI9wcc5KXKbuHaf8puoEzZqLBGj7EGDrRUgI+Xzhu6dY3 f90i6AUtzaK40DAofyTbB11u0g0dLuyl7taWAtTgwWmcSP8xZF3uzubms/CjKAblnyoD AZ0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Ql/QslLI"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i124si6720789oif.214.2020.02.17.06.23.10; Mon, 17 Feb 2020 06:23:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Ql/QslLI"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728567AbgBQOQ4 (ORCPT + 99 others); Mon, 17 Feb 2020 09:16:56 -0500 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:53771 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726788AbgBQOQ4 (ORCPT ); Mon, 17 Feb 2020 09:16:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581949015; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=X5owJ1Q5kyCcEn/wK666suwQNxuxUfzmbCXN/IZugIc=; b=Ql/QslLIYBgfgKNU7L0Xfdjyx8FBxDJ4HLpO6fHytDF2YVc/hw42J0d20hJz69sd1geY44 tiYj9X0ud2lRGGkXm7dgjFVocdKavaaxMKDqMl0e2jq01gLKHCMgEDNwAoJyiQdGaW9hgx m/iCr1EGVIH+qsxZdlaxS7OMBZSn25E= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-425-iBpcNIS-NpSKzol34DWwMA-1; Mon, 17 Feb 2020 09:16:49 -0500 X-MC-Unique: iBpcNIS-NpSKzol34DWwMA-1 Received: by mail-wr1-f69.google.com with SMTP id 90so9008384wrq.6 for ; Mon, 17 Feb 2020 06:16:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=X5owJ1Q5kyCcEn/wK666suwQNxuxUfzmbCXN/IZugIc=; b=YnfQhO8x9ZuPYWtko4VKWdwDU/Wd7aHagwwu7cCVEL7xe0Fzfa9UYUbIfSJve6HTzN JeA0vKmR/OcL9x+APQyKHupFb2SdAhZpz8+G/J1L4WlJ7rPZc5hkbfwtXcuhzj5IZc5V 59/GRnpPPZL9yUKhA67EcJItHGWxrLm7Z0pI0uWX/rBEOpR6IMmnzDxeeNKbSgCzoodM 8eZxLGPuHCrdK6yNzqRwCDA1sZ6A3pXxzh8OS6zENyYPWFOarj0L5PEwl5KIGe8Z+cMn n7VIYM8F8K1EM0CMfCXJWEquq3sfSEb0AhvMZITVVPKpbb+UbOyu+DHvPEVH831kmvW1 4sVw== X-Gm-Message-State: APjAAAW5aLNWLAqi2YfusmJQB5enLACvrJgqnkKzaDB/Ad0evVJWrJHn 9In49CbYfQC6mOP1LjmRychlokm+qnpEcIRVcxQ81m8dqyKeqRA25DtxcC1xVB9pcGpSEnyCUwc EKhmEG7nyQoIFQKdQeBIV1tst X-Received: by 2002:a1c:ddc3:: with SMTP id u186mr22709062wmg.103.1581949008356; Mon, 17 Feb 2020 06:16:48 -0800 (PST) X-Received: by 2002:a1c:ddc3:: with SMTP id u186mr22709044wmg.103.1581949008070; Mon, 17 Feb 2020 06:16:48 -0800 (PST) Received: from vitty.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id u62sm830661wmu.17.2020.02.17.06.16.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Feb 2020 06:16:47 -0800 (PST) From: Vitaly Kuznetsov To: Wanpeng Li Cc: Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel , LKML , kvm Subject: Re: [PATCH v2 2/2] KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis In-Reply-To: References: <871rqtbcve.fsf@vitty.brq.redhat.com> Date: Mon, 17 Feb 2020 15:16:46 +0100 Message-ID: <87y2t19u41.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wanpeng Li writes: > On Mon, 17 Feb 2020 at 20:46, Vitaly Kuznetsov wrote: >> >> Wanpeng Li writes: >> >> > From: Wanpeng Li >> > >> > Nick Desaulniers Reported: >> > >> > When building with: >> > $ make CC=clang arch/x86/ CFLAGS=-Wframe-larger-than=1000 >> > The following warning is observed: >> > arch/x86/kernel/kvm.c:494:13: warning: stack frame size of 1064 bytes in >> > function 'kvm_send_ipi_mask_allbutself' [-Wframe-larger-than=] >> > static void kvm_send_ipi_mask_allbutself(const struct cpumask *mask, int >> > vector) >> > ^ >> > Debugging with: >> > https://github.com/ClangBuiltLinux/frame-larger-than >> > via: >> > $ python3 frame_larger_than.py arch/x86/kernel/kvm.o \ >> > kvm_send_ipi_mask_allbutself >> > points to the stack allocated `struct cpumask newmask` in >> > `kvm_send_ipi_mask_allbutself`. The size of a `struct cpumask` is >> > potentially large, as it's CONFIG_NR_CPUS divided by BITS_PER_LONG for >> > the target architecture. CONFIG_NR_CPUS for X86_64 can be as high as >> > 8192, making a single instance of a `struct cpumask` 1024 B. >> > >> > This patch fixes it by pre-allocate 1 cpumask variable per cpu and use it for >> > both pv tlb and pv ipis.. >> > >> > Reported-by: Nick Desaulniers >> > Acked-by: Nick Desaulniers >> > Cc: Peter Zijlstra >> > Cc: Nick Desaulniers >> > Signed-off-by: Wanpeng Li >> > --- >> > v1 -> v2: >> > * remove '!alloc' check >> > * use new pv check helpers >> > >> > arch/x86/kernel/kvm.c | 33 +++++++++++++++++++++------------ >> > 1 file changed, 21 insertions(+), 12 deletions(-) >> > >> > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c >> > index 76ea8c4..377b224 100644 >> > --- a/arch/x86/kernel/kvm.c >> > +++ b/arch/x86/kernel/kvm.c >> > @@ -432,6 +432,8 @@ static bool pv_tlb_flush_supported(void) >> > kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)); >> > } >> > >> > +static DEFINE_PER_CPU(cpumask_var_t, __pv_cpu_mask); >> > + >> > #ifdef CONFIG_SMP >> > >> > static bool pv_ipi_supported(void) >> > @@ -510,12 +512,12 @@ static void kvm_send_ipi_mask(const struct >> > cpumask *mask, int vector) >> > static void kvm_send_ipi_mask_allbutself(const struct cpumask *mask, >> > int vector) >> > { >> > unsigned int this_cpu = smp_processor_id(); >> > - struct cpumask new_mask; >> > + struct cpumask *new_mask = this_cpu_cpumask_var_ptr(__pv_cpu_mask); >> > const struct cpumask *local_mask; >> > >> > - cpumask_copy(&new_mask, mask); >> > - cpumask_clear_cpu(this_cpu, &new_mask); >> > - local_mask = &new_mask; >> > + cpumask_copy(new_mask, mask); >> > + cpumask_clear_cpu(this_cpu, new_mask); >> > + local_mask = new_mask; >> > __send_ipi_mask(local_mask, vector); >> > } >> > >> > @@ -595,7 +597,6 @@ static void __init kvm_apf_trap_init(void) >> > update_intr_gate(X86_TRAP_PF, async_page_fault); >> > } >> > >> > -static DEFINE_PER_CPU(cpumask_var_t, __pv_tlb_mask); >> > >> > static void kvm_flush_tlb_others(const struct cpumask *cpumask, >> > const struct flush_tlb_info *info) >> > @@ -603,7 +604,7 @@ static void kvm_flush_tlb_others(const struct >> > cpumask *cpumask, >> > u8 state; >> > int cpu; >> > struct kvm_steal_time *src; >> > - struct cpumask *flushmask = this_cpu_cpumask_var_ptr(__pv_tlb_mask); >> > + struct cpumask *flushmask = this_cpu_cpumask_var_ptr(__pv_cpu_mask); >> > >> > cpumask_copy(flushmask, cpumask); >> > /* >> > @@ -642,6 +643,7 @@ static void __init kvm_guest_init(void) >> > if (pv_tlb_flush_supported()) { >> > pv_ops.mmu.flush_tlb_others = kvm_flush_tlb_others; >> > pv_ops.mmu.tlb_remove_table = tlb_remove_table; >> > + pr_info("KVM setup pv remote TLB flush\n"); >> >> Nit: to be consistent with __send_ipi_mask() the message should be >> somthing like >> >> "KVM: switch to using PV TLB flush" > > There is a lot of native ops we replace by pv ops in kvm.c, I use "KVM > setup xxx" there, like pv ipis, pv tlb flush, pv sched yield, should > we keep consistent as before? > Oh, I see, it's either one or another :-) Personally, I prefer when subsystem is delimited with ':' so if we were to change them all I'd prefer the "KVM: switch to using PV TLB flush" (__send_ipi_mask() style). But this looks more like a separate patch idea, we can discuss our personal preferences there :-) -- Vitaly