All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Matlack <dmatlack@google.com>
To: Vipin Sharma <vipinsh@google.com>
Cc: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>, KVM <kvm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ben Gardon <bgardon@google.com>
Subject: Re: [Patch v2 2/2] KVM: x86/mmu: Allocate page table pages on NUMA node of underlying pages
Date: Thu, 8 Dec 2022 16:06:26 -0800	[thread overview]
Message-ID: <Y5J8ArpcVVyBm3CY@google.com> (raw)
In-Reply-To: <CAHVum0dPRqOmoMQsjV5M0kcaccqTpfwou0zrMj1R1RUYMFBjEg@mail.gmail.com>

On Wed, Dec 07, 2022 at 11:05:09AM -0800, Vipin Sharma wrote:
> By mistake I started replying to just Ben and realized it after few
> exchanges. Adding others. Sorry about that.
> 
> On Wed, Dec 7, 2022 at 10:58 AM Vipin Sharma <vipinsh@google.com> wrote:
> >
> > On Tue, Dec 6, 2022 at 11:57 AM Ben Gardon <bgardon@google.com> wrote:
> > >
> > > On Tue, Dec 6, 2022 at 11:18 AM Vipin Sharma <vipinsh@google.com> wrote:
> > > >
> > > > On Tue, Dec 6, 2022 at 10:17 AM Ben Gardon <bgardon@google.com> wrote:
> > > > >
> > > > > On Mon, Dec 5, 2022 at 3:40 PM Vipin Sharma <vipinsh@google.com> wrote:
> > > > > >
> > > > > > On Mon, Dec 5, 2022 at 10:17 AM Ben Gardon <bgardon@google.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 1, 2022 at 11:57 AM Vipin Sharma <vipinsh@google.com> wrote:
> > > > > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > > > > > > index 1782c4555d94..4d59c9d48277 100644
> > > > > > > > --- a/virt/kvm/kvm_main.c
> > > > > > > > +++ b/virt/kvm/kvm_main.c
> > > > > > > > @@ -384,6 +384,11 @@ static void kvm_flush_shadow_all(struct kvm *kvm)
> > > > > > > >         kvm_arch_guest_memory_reclaimed(kvm);
> > > > > > > >  }
> > > > > > > >
> > > > > > > > +void * __weak kvm_arch_mmu_get_free_page(int nid, gfp_t gfp_flags)
> > > > > > > > +{
> > > > > > > > +               return (void *)__get_free_page(gfp_flags);
> > > > > > > > +}
> > > > > > > > +
> > > > > > >
> > > > > > > Rather than making this __weak, you could use #ifdef CONFIG_NUMA to
> > > > > > > just put all the code in the arch-neutral function.
> > > > > > >
> > > > > >
> > > > > > I am not sure how it will work. Here, I am trying to keep this feature
> > > > > > only for x86. This function will be used for all architecture except
> > > > > > in x86 where we have different implementation in arch/x86/mmu/mmu.c
> > > > > > So, even if CONFIG_NUMA is defined, we want to keep the same
> > > > > > definition on other architectures.
> > > > > >
> > > > > >
> > > > >
> > > > > Something like:
> > > > >
> > > > > +void * kvm_arch_mmu_get_free_page(int nid, gfp_t gfp_flags)
> > > > > +{
> > > > > +       struct page *spt_page;
> > > > > +       void *address = NULL;
> > > > > +
> > > > > +       #ifdef CONFIG_NUMA
> > > > > +       if (nid != NUMA_NO_NODE) {
> > > > > +               spt_page = alloc_pages_node(nid, gfp, 0);
> > > > > +               if (spt_page) {
> > > > > +                       address = page_address(spt_page);
> > > > > +                       return address;
> > > > > +               }
> > > > > +       }
> > > > > +       #endif // CONFIG_NUMA
> > > > > +       return (void *)__get_free_page(gfp);
> > > > > +}
> > > > >
> > > >
> > > > 'nid' will be 0 not NUMA_NO_NODE for other architectures. In x86, I am
> > > > explicitly setting kvm_mmu_memory_cache->node to NUMA_NO_NODE or
> > > > specific desired nodes. In others architectures it will be 0 as struct
> > > > will be 0 initialized. __weak avoids initializing nid to NUM_NO_NODE
> > > > in other architectures.
> > >
> > > ooh, I see. It might be worth setting it to NUMA_NO_NODE on other
> > > archs as 0 could be kind of misleading.
> >
> > Discussed offline with Ben.
> > Initialization code for cache is in the respective architectures.
> > Using "__weak" avoids touching code in other architectures.

But it's still a bit gross to have node=0 in struct
kvm_mmu_memory_cache for other architectures, even if it doesn't happen
to be misused in this series.

I would just bite the bullet and modify the other architectures. Do it
in a precusor patch where you just add node to struct
kvm_mmu_memory_cache and initialize it to NUMA_NO_NODE across all
architectures, probably with a common macro e.g.

#define INIT_KVM_MMU_MEMORY_CACHE(_cache) do { \
	(_cache)->node = NUMA_NO_NODE; \
} while (0)

Then, you can follow Ben's approach and avoid the __weak function.

  reply	other threads:[~2022-12-09  0:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 19:57 [Patch v2 0/2] NUMA aware page table allocation Vipin Sharma
2022-12-01 19:57 ` [Patch v2 1/2] KVM: x86/mmu: Allocate page table pages on TDP splits during dirty log enable on the underlying page's numa node Vipin Sharma
2022-12-05 18:24   ` Ben Gardon
2022-12-05 18:47     ` Sean Christopherson
2022-12-05 18:51       ` Ben Gardon
2022-12-05 21:07         ` Sean Christopherson
2022-12-08 22:44           ` Vipin Sharma
2022-12-01 19:57 ` [Patch v2 2/2] KVM: x86/mmu: Allocate page table pages on NUMA node of underlying pages Vipin Sharma
2022-12-05 18:17   ` Ben Gardon
2022-12-05 23:40     ` Vipin Sharma
2022-12-06 18:17       ` Ben Gardon
     [not found]         ` <CAHVum0f_6UQvcqWAJxDJyL_LN-6ryAXNuh9xY6nFtLxCOMtoXA@mail.gmail.com>
     [not found]           ` <CANgfPd-XkHPZyFsPe75WbUrufLpKtdr1Neri1JrrApQrjRLRJw@mail.gmail.com>
     [not found]             ` <CAHVum0dkKSY9e90xgfBVBHUqntwJOmONK+TYBXFEwg6acvUrAw@mail.gmail.com>
2022-12-07 19:05               ` Vipin Sharma
2022-12-09  0:06                 ` David Matlack [this message]
2022-12-09 18:47                   ` Vipin Sharma
2022-12-09  0:27   ` David Matlack
2022-12-09 18:51     ` Vipin Sharma
2022-12-09  0:21 ` [Patch v2 0/2] NUMA aware page table allocation David Matlack

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=Y5J8ArpcVVyBm3CY@google.com \
    --to=dmatlack@google.com \
    --cc=bgardon@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=vipinsh@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.