Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1893759rwb; Thu, 8 Dec 2022 17:08:17 -0800 (PST) X-Google-Smtp-Source: AA0mqf5aUfu2s6o6w95jtnnX4w54syHpwUH516/CxYJjivemXt56WLIiwTQg44iEnqp6556rOxki X-Received: by 2002:aa7:cb19:0:b0:469:65a4:9127 with SMTP id s25-20020aa7cb19000000b0046965a49127mr3167472edt.17.1670548097209; Thu, 08 Dec 2022 17:08:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670548097; cv=none; d=google.com; s=arc-20160816; b=qgmKxPtMLBAVh9mrjF675UJI1+oQJU/xrUJZ+BZaW7KL9d8rI7Rgsbq7wMSGzu5jVE l2LEnarsu0Y037Xhvo4hhhXFnfIXOszBsW//n193ik3QJ48FL7MiRjGGtRXoAxU+P117 LacV9h2AmpKisGdhtVJjgTRjTLVO0srP4/GqnA0hZ/1Ul8g+XjJU3B/tRk7Jhr+YNb9B bFxKOV7C2XMvCzesPf9q32hQs+YIdQtILxNZrerRVy0URhaBTbY/6xj9Kx2jCdtFdVRk wNCE2gz9hR/uq2irPqjmJBJn0xDgWbDosxxMtDMtMUBV/kADA8xxV1NHaD0n+/lK71KR VRDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eW8K+BNldesCck4OAbowATcCZnmQD+hw+9oKUlYQOq4=; b=v9qThtWfiwLlGjKLRLnNkD1Fa3MbOU1RRa2tSAZk0brRFH8R8oXumuGs3TFXr8UWWc ODDZ2BoZWS3G1yvTItvpjYpSUR60QkoHGhVkMrPjW8LDkXHk7QtGUcoSuxgfkCN0waZ0 qpx+bPf2KJ+yZCNW+Fe+N0Wio6Jpiah7oL3ZnGLxJce+kblF241siHLMl96R4hHsLxa/ BbIqR6ZuRvStQJ3I4wCv8r2GAdeXwrg1jNyuMU+JK/L09trNPnOUhneFGIkfkrn+IVEC WrWVFufY7F4+Z63OlDiOUeRr0UibdRf+pcE9JOcjONJGE7ZKuWdN9HbrVq0jl7DeWE34 O28w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bkTXzjhf; 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 gt7-20020a1709072d8700b007897abd2d17si17773410ejc.468.2022.12.08.17.07.58; Thu, 08 Dec 2022 17:08:17 -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=bkTXzjhf; 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 S229571AbiLIA2F (ORCPT + 73 others); Thu, 8 Dec 2022 19:28:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbiLIA2D (ORCPT ); Thu, 8 Dec 2022 19:28:03 -0500 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B0A679CAC for ; Thu, 8 Dec 2022 16:28:02 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id q71so2477595pgq.8 for ; Thu, 08 Dec 2022 16:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eW8K+BNldesCck4OAbowATcCZnmQD+hw+9oKUlYQOq4=; b=bkTXzjhfbYiNZ+Ervu84V0OZVxkj1edOwaSMuQTy3OCKDHnHqezISJCZnTAJBTet/N jh1QgIjNZ7jVPXHP4cQf1cy4XZ3fvqHRqHLc27cGsbafcKUWYQ++Gia0bm2zev1UEYXg 6C2MSafq75ay43dmAbNWgl/PWivnVQY0mJ/7vIrb5IjSNn2hPMnI8K1YDRA/D2H2Vv5/ r5Wo9RaewBy6qkVEeqFWbfaPB1zHxPfGSDHDy0c9nm/wtWFv+wG5R+9Wdiq7cRqDRAAn K/Be2lPXIUblVr8+Bf9zCaPqtUU5c/13qrX6kECFzjcoLnwPMyf+3rJjFlgQ83aRpXnJ iadw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eW8K+BNldesCck4OAbowATcCZnmQD+hw+9oKUlYQOq4=; b=LefFVDNx+57c/1w3AExf0om/QUfGeSIm13a/ldUbYTOfcyuW74SIwk29s734TJ8g2P n99RgaAkEQ7qzVL+mge9h3TTP90NXLDoaeN+yHb3B52olGZw4kFn7iyZFm4N9jjDkEkg ekiZuerbwg4Nenl2xJTUPjO6UYNZF4965hjP0uhki949etQZ7ZyUvboZFdOLwfUPWkUb OhEvEn1sEErlY0tRkG3V6V+Qyfzgz/RSwmm3LDzsY45aH+s1/SVtf8TZyDi9c7Alz/Cx 7DB5ZvDyZLr8eRwnof8x+SxLfJckgi6UfkxsmLLE1uav3/haIu2Lqvhs6gTQyd6eWWv0 M34g== X-Gm-Message-State: ANoB5pnE1u8Opvprl6TunUBkNGyZZRuEZtXtVWmLGEmIjEz6OVooCuUS gGv/krKZuZl1wFDOeAbEZ6gq1Q== X-Received: by 2002:a62:5501:0:b0:566:900e:1031 with SMTP id j1-20020a625501000000b00566900e1031mr3441900pfb.17.1670545681794; Thu, 08 Dec 2022 16:28:01 -0800 (PST) Received: from google.com (223.103.125.34.bc.googleusercontent.com. [34.125.103.223]) by smtp.gmail.com with ESMTPSA id p127-20020a62d085000000b00562677968aesm87230pfg.72.2022.12.08.16.28.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 16:28:01 -0800 (PST) Date: Thu, 8 Dec 2022 16:27:57 -0800 From: David Matlack To: Vipin Sharma Cc: bgardon@google.com, seanjc@google.com, pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Patch v2 2/2] KVM: x86/mmu: Allocate page table pages on NUMA node of underlying pages Message-ID: References: <20221201195718.1409782-1-vipinsh@google.com> <20221201195718.1409782-3-vipinsh@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221201195718.1409782-3-vipinsh@google.com> 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 Thu, Dec 01, 2022 at 11:57:18AM -0800, Vipin Sharma wrote: > Page table pages of a VM are currently allocated based on the current > task's NUMA node or its mempolicy. This can cause suboptimal remote > accesses by the vCPU if it is accessing physical pages local to its NUMA > node but the page table pages mapping those physcal pages were created > by some other vCPU which was on different NUMA node or had different > policy. > > Allocate page table pages on the same NUMA node where underlying > physical page exists. Page table at level 5, 4, and 3 might not end up > on the same NUMA node as they can span multiple NUMA nodes. > > Signed-off-by: Vipin Sharma > --- ... > @@ -6284,13 +6326,16 @@ static int shadow_mmu_try_split_huge_page(struct kvm *kvm, > gfn = kvm_mmu_page_get_gfn(huge_sp, spte_index(huge_sptep)); > level = huge_sp->role.level; > spte = *huge_sptep; > + nid = kvm_pfn_to_refcounted_page_nid(spte_to_pfn(spte)); > + if (nid == NUMA_NO_NODE) > + nid = numa_mem_id(); What do you think about renaming kvm_pfn_to_refcounted_page_nid() to kvm_pfn_to_page_table_nid() and having it return numa_mem_id() instead of NUMA_NO_NODE (with a comment)? I think that will clean up this patch quite a bit by getting rid of all the NUMA_NO_NODE checks.