All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Peter Gonda <pgonda@google.com>,
	Li RongQing <lirongqing@baidu.com>,
	pbonzini@redhat.com,  kvm@vger.kernel.org,
	Tom Lendacky <thomas.lendacky@amd.com>,
	 Michael Roth <michael.roth@amd.com>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH] KVM: SVM: Consider NUMA affinity when allocating per-CPU save_area
Date: Tue, 23 Apr 2024 11:43:46 -0700	[thread overview]
Message-ID: <ZigBYpHubg00BnAT@google.com> (raw)
In-Reply-To: <CAJD7tkZzHQUOH3EiJ_Zn33dya+pumnohoKA7AnnVm4GE+WcOhg@mail.gmail.com>

On Tue, Apr 23, 2024, Yosry Ahmed wrote:
> On Tue, Apr 23, 2024 at 6:30 AM Peter Gonda <pgonda@google.com> wrote:
> > > struct page *snp_safe_alloc_page(int cpu)
> > > {
> > >         unsigned long pfn;
> > >         struct page *p;
> > >         gfp_t gpf;
> > >         int node;
> > >
> > >         if (cpu >= 0) {
> > >                 node = cpu_to_node(cpu);
> > >                 gfp = GFP_KERNEL;
> > >         } else {
> > >                 node = NUMA_NO_NODE;
> > >                 gfp = GFP_KERNEL_ACCOUNT
> > >         }
> 
> FWIW, from the pov of someone who has zero familiarity with this code,
> passing @cpu only to make inferences about the GFP flags and numa
> nodes is confusing tbh.
> 
> Would it be clearer to pass in the gfp flags and node id directly? I
> think it would make it clearer why we choose to account the allocation
> and/or specify a node in some cases but not others.

Hmm, yeah, passing GFP directly makes sense, if only to align with alloc_page()
and not reinvent the wheel.  But forcing all callers to explicitly provide a node
ID is a net negative, i.e. having snp_safe_alloc_page() and snp_safe_alloc_page_node()
as originally suggested makes sense.

But snp_safe_alloc_page() should again flow alloc_pages() and pass numa_node_id(),
not NUMA_NO_NODE.

  reply	other threads:[~2024-04-23 18:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18  3:07 [PATCH] KVM: SVM: Consider NUMA affinity when allocating per-CPU save_area Li RongQing
2024-04-23  0:29 ` Sean Christopherson
2024-04-23 13:30   ` Peter Gonda
2024-04-23 18:00     ` Yosry Ahmed
2024-04-23 18:43       ` Sean Christopherson [this message]
2024-04-23 18:52         ` Yosry Ahmed
2024-04-23 19:00           ` Sean Christopherson
2024-04-23 19:08             ` Yosry Ahmed
2024-04-23 20:38               ` Tom Lendacky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZigBYpHubg00BnAT@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=rientjes@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.