Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp3597978rwl; Tue, 27 Dec 2022 11:40:36 -0800 (PST) X-Google-Smtp-Source: AMrXdXvz1QGEdxsQZi78TsIxvccA7DqGX+T49O2PvhdtMyFFCM/e2rCspJq4j1HNBQWmQRWEjfdz X-Received: by 2002:a05:6a20:b706:b0:a3:a1ee:47ca with SMTP id fg6-20020a056a20b70600b000a3a1ee47camr26312760pzb.46.1672170036043; Tue, 27 Dec 2022 11:40:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672170036; cv=none; d=google.com; s=arc-20160816; b=iGuAx56qQQ3E90Ce8mzY9ZLPX6Pu9krqPpq0LMHI61cJt7iymX/Gw363asaT35fn60 p7YEUOJNECMzGBoLCT6lRu+AkhmJOJ69ibLJ4OFpzj5mP+WvkSsMO6RUCxyXTfvwb552 TSkBlC5E2kFx0KvAMk/yKigBQB3OlhCKLe4UrTwbVrdaz+KfawNjVTHYUwkhGmICdWWK BVIWV6PfkPtJ6rEm6fizi5flzjWpcGCR3VmwbRL8Z8wT1lq49lHCgAHXiCC9A30pZHJG ZWDnswBpVBqbshJOE2MRFbDr6R9fEPmdN3jUdx1VQLDoxCERdmc07az9RUL0jIb52BiG ZETQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=E2gUvzefuGQfzRw3IXsN/yQhJ7wb3oyMnqOzM2W06bQ=; b=jd3ZZSUrPaOfzZcRAoHIYU4aT/ewAzem7Ats7sGWVoLUPUwWUQPBEbcmiRB/w766pd gHB7nVgvPtt8NjMnTY0F4ZRnnF4oV6JDFt8B4HuorO74iTs1UwM+P9cqQ/nucTuDI6eU vxoldf95cg5A09yPM9v0vSIIZgpH7BzRo+hyiSe0JZc6FGTcIirBVGYADr4XodcGvO6u RBNdmBaiYnJG7j9REcWz6xQYSJawELVICEu5F4rY0Fhjy8I+XRw3pzMsBs6OJXKngTOM Cu5qXrV8/CnMEVUFRRuRulC3b7Wd014YNnLXpiFVuZ53ofpxW5GDbRZ60bWg9mMeozZt O1yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=LCRBRzVC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 29-20020a17090a1a5d00b00225da94a953si9337479pjl.165.2022.12.27.11.40.27; Tue, 27 Dec 2022 11:40:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=LCRBRzVC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230407AbiL0TKH (ORCPT + 66 others); Tue, 27 Dec 2022 14:10:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230293AbiL0TKE (ORCPT ); Tue, 27 Dec 2022 14:10:04 -0500 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB566CE12 for ; Tue, 27 Dec 2022 11:10:02 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id vm8so26941427ejc.2 for ; Tue, 27 Dec 2022 11:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=E2gUvzefuGQfzRw3IXsN/yQhJ7wb3oyMnqOzM2W06bQ=; b=LCRBRzVCt4dH/C/m9t2Z09K8t9q1oIWgw9rUBHmQu0CyHyqqoPASd2FEHEVwLQT4Jb kO2svJ5hRkoimvsLdjZ+uRge/YW1H6iplS5QmxcmVo7erSyjftmnzryjVR/E0PTIsiTJ Ua9BwgRYnEsuvdy8bUsFGkRbqpcMqxTAl924S5vGFov7JmgznRINm6m2rFbbN9eXihhA MaP6j0iRHLPk40TJi/KNvgA7iKl2RmcBUCwjnEuw8jJt8Ku7satSQoABBYKkEpokd3IR oUijaerUXs37GFFYHbxYwimqmvCV9/8iYfheCoXYHA1iahdTSV0lC6bFohpuHgD74Xkl 1CJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E2gUvzefuGQfzRw3IXsN/yQhJ7wb3oyMnqOzM2W06bQ=; b=SwnH9QyLSfkN95F/e7cNZcHeGR/6bo5/HmPRJNseluSd/NaT1/ifBFHhCCaQizFqHZ JUfSCr/Lo+9upO9BnP0qKCptrTHGVpTFYqI7UhdQjn4kbwI/707lo4+Qo1Dsl/fg7LWd Z23TTtIBVysM+x1rv2azG69ig4eTKv+uZypV78DkkgYea5idERK5kh6yGDpwzBDlOT+y AkWNAbP8RqWMyxx0CyqyKXpsW4PiOmMYaLVAyc6B5TbPoZhZYhMvxqQ1qaFP3fcfJAAK tzpN3jpccZePkUDSdztniff48B36Z/ytyoHBxiBU7IrihP+ZKuuSGgsPIy8qAEak6MuV WwvA== X-Gm-Message-State: AFqh2kqHdmIQfoLsWWL5M9203ad5R+tPvyjYTRVehXL6ysbLMsql0SQn AgtVPN8WEk//5+iOcr3GDzKrT9SYjyvIUPvD0331FQ== X-Received: by 2002:a17:906:6955:b0:7de:e268:2069 with SMTP id c21-20020a170906695500b007dee2682069mr2218428ejs.341.1672168201311; Tue, 27 Dec 2022 11:10:01 -0800 (PST) MIME-Version: 1.0 References: <20221222023457.1764-1-vipinsh@google.com> <20221222023457.1764-7-vipinsh@google.com> In-Reply-To: <20221222023457.1764-7-vipinsh@google.com> From: Ben Gardon Date: Tue, 27 Dec 2022 11:09:49 -0800 Message-ID: Subject: Re: [Patch v3 6/9] KVM: Provide NUMA node support to kvm_mmu_memory_cache{} To: Vipin Sharma Cc: seanjc@google.com, pbonzini@redhat.com, dmatlack@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 21, 2022 at 6:35 PM Vipin Sharma wrote: > > Add 'node' variable in kvm_mmu_memory_cache{} to denote which NUMA node > this cache should allocate memory from. Default initialize to > NUMA_NO_NODE in all architectures. > > Signed-off-by: Vipin Sharma > --- > arch/arm64/kvm/arm.c | 2 +- > arch/arm64/kvm/mmu.c | 4 +++- > arch/mips/kvm/mips.c | 2 ++ > arch/riscv/kvm/mmu.c | 2 +- > arch/riscv/kvm/vcpu.c | 2 +- > arch/x86/kvm/mmu/mmu.c | 22 ++++++++++++---------- > include/linux/kvm_host.h | 6 ++++++ > include/linux/kvm_types.h | 2 ++ > 8 files changed, 28 insertions(+), 14 deletions(-) > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 9c5573bc4614..52a41f4532e2 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -340,7 +340,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > vcpu->arch.target = -1; > bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES); > > - vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&vcpu->arch.mmu_page_cache, NULL, NUMA_NO_NODE); > > /* > * Default value for the FP state, will be overloaded at load > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 31d7fa4c7c14..bd07155e17fa 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -894,12 +894,14 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa, > { > phys_addr_t addr; > int ret = 0; > - struct kvm_mmu_memory_cache cache = { .gfp_zero = __GFP_ZERO }; > + struct kvm_mmu_memory_cache cache; > struct kvm_pgtable *pgt = kvm->arch.mmu.pgt; > enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_DEVICE | > KVM_PGTABLE_PROT_R | > (writable ? KVM_PGTABLE_PROT_W : 0); > > + INIT_KVM_MMU_MEMORY_CACHE(&cache, NULL, NUMA_NO_NODE); > + > if (is_protected_kvm_enabled()) > return -EPERM; > > diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c > index a25e0b73ee70..b017c29a9340 100644 > --- a/arch/mips/kvm/mips.c > +++ b/arch/mips/kvm/mips.c > @@ -304,6 +304,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > HRTIMER_MODE_REL); > vcpu->arch.comparecount_timer.function = kvm_mips_comparecount_wakeup; > > + vcpu->arch.mmu_page_cache.node = NUMA_NO_NODE; > + It looks weird to have MIPS not using the initialization MACRO. Should it just have a GFP_ZERO parameter? > /* > * Allocate space for host mode exception handlers that handle > * guest mode exits > diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c > index 34b57e0be2ef..119de4520cc6 100644 > --- a/arch/riscv/kvm/mmu.c > +++ b/arch/riscv/kvm/mmu.c > @@ -353,9 +353,9 @@ int kvm_riscv_gstage_ioremap(struct kvm *kvm, gpa_t gpa, > phys_addr_t addr, end; > struct kvm_mmu_memory_cache pcache = { > .gfp_custom = (in_atomic) ? GFP_ATOMIC | __GFP_ACCOUNT : 0, > - .gfp_zero = __GFP_ZERO, > }; > > + INIT_KVM_MMU_MEMORY_CACHE(&pcache, NULL, NUMA_NO_NODE); > end = (gpa + size + PAGE_SIZE - 1) & PAGE_MASK; > pfn = __phys_to_pfn(hpa); > > diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c > index 7c08567097f0..189b14feb365 100644 > --- a/arch/riscv/kvm/vcpu.c > +++ b/arch/riscv/kvm/vcpu.c > @@ -161,7 +161,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > > /* Mark this VCPU never ran */ > vcpu->arch.ran_atleast_once = false; > - vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&vcpu->arch.mmu_page_cache, NULL, NUMA_NO_NODE); > bitmap_zero(vcpu->arch.isa, RISCV_ISA_EXT_MAX); > > /* Setup ISA features available to VCPU */ > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 6f6a10d7a871..23a3b82b2384 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -5954,13 +5954,14 @@ int kvm_mmu_create(struct kvm_vcpu *vcpu) > { > int ret; > > - vcpu->arch.mmu_pte_list_desc_cache.kmem_cache = pte_list_desc_cache; > - vcpu->arch.mmu_pte_list_desc_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&vcpu->arch.mmu_pte_list_desc_cache, > + pte_list_desc_cache, NUMA_NO_NODE); > > - vcpu->arch.mmu_page_header_cache.kmem_cache = mmu_page_header_cache; > - vcpu->arch.mmu_page_header_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&vcpu->arch.mmu_page_header_cache, > + mmu_page_header_cache, NUMA_NO_NODE); > > - vcpu->arch.mmu_shadow_page_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&vcpu->arch.mmu_shadow_page_cache, > + NULL, NUMA_NO_NODE); > spin_lock_init(&vcpu->arch.mmu_shadow_page_cache_lock); > > vcpu->arch.mmu = &vcpu->arch.root_mmu; > @@ -6124,14 +6125,15 @@ int kvm_mmu_init_vm(struct kvm *kvm) > node->track_flush_slot = kvm_mmu_invalidate_zap_pages_in_memslot; > kvm_page_track_register_notifier(kvm, node); > > - kvm->arch.split_page_header_cache.kmem_cache = mmu_page_header_cache; > - kvm->arch.split_page_header_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&kvm->arch.split_page_header_cache, > + mmu_page_header_cache, NUMA_NO_NODE); > > - kvm->arch.split_shadow_page_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&kvm->arch.split_shadow_page_cache, > + NULL, NUMA_NO_NODE); > spin_lock_init(&kvm->arch.split_shadow_page_cache_lock); > > - kvm->arch.split_desc_cache.kmem_cache = pte_list_desc_cache; > - kvm->arch.split_desc_cache.gfp_zero = __GFP_ZERO; > + INIT_KVM_MMU_MEMORY_CACHE(&kvm->arch.split_desc_cache, > + pte_list_desc_cache, NUMA_NO_NODE); > > return 0; > } > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index a262e15ebd19..719687a37ef7 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -2302,4 +2302,10 @@ static inline void kvm_account_pgtable_pages(void *virt, int nr) > /* Max number of entries allowed for each kvm dirty ring */ > #define KVM_DIRTY_RING_MAX_ENTRIES 65536 > > +#define INIT_KVM_MMU_MEMORY_CACHE(_cache, _kmem_cache, _node) ({ \ > + (_cache)->kmem_cache = _kmem_cache; \ > + (_cache)->gfp_zero = __GFP_ZERO; \ > + (_cache)->node = _node; \ > +}) > + Given that this initialization is probably not happening in a super hot path, is there any downside to just using a function for the initialization? > #endif > diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h > index 76de36e56cdf..9c70ce95e51f 100644 > --- a/include/linux/kvm_types.h > +++ b/include/linux/kvm_types.h > @@ -97,6 +97,8 @@ struct kvm_mmu_memory_cache { > struct kmem_cache *kmem_cache; > int capacity; > void **objects; > + /* Node on which memory should be allocated by default */ > + int node; > }; > #endif > > -- > 2.39.0.314.g84b9a713c41-goog >