From: Sean Christopherson <seanjc@google.com>
To: David Matlack <dmatlack@google.com>
Cc: Vipin Sharma <vipinsh@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm list <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86/mmu: Make page tables for eager page splitting NUMA aware
Date: Tue, 9 Aug 2022 23:51:41 +0000 [thread overview]
Message-ID: <YvLzDUjpJHmZtn0i@google.com> (raw)
In-Reply-To: <CALzav=ccxkAWk7ddqbJ_qPL2-=bXVZUEpWgwKpJ1oCtc_8w7WQ@mail.gmail.com>
On Tue, Aug 09, 2022, David Matlack wrote:
> On Fri, Aug 5, 2022 at 4:30 PM Vipin Sharma <vipinsh@google.com> wrote:
> > Approach B:
> > Ask page from the specific node on fault path with option to fallback
> > to the original cache and default task policy.
> >
> > This is what Sean's rough patch looks like.
>
> This would definitely be a simpler approach but could increase the
> amount of time a vCPU thread holds the MMU lock when handling a fault,
> since KVM would start performing GFP_NOWAIT allocations under the
> lock. So my preference would be to try the cache approach first and
> see how complex it turns out to be.
Ya, as discussed off-list, I don't like my idea either :-)
The pfn and thus node information is available before mmu_lock is acquired, so I
don't see any reason to defer the allocation other than to reduce the memory
footprint, and that's a solvable problem one way or another.
prev parent reply other threads:[~2022-08-09 23:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 15:19 [PATCH] KVM: x86/mmu: Make page tables for eager page splitting NUMA aware Vipin Sharma
2022-08-01 22:10 ` David Matlack
2022-08-01 23:56 ` Sean Christopherson
2022-08-02 16:31 ` David Matlack
2022-08-02 17:22 ` Sean Christopherson
2022-08-02 17:42 ` Paolo Bonzini
2022-08-02 19:12 ` Sean Christopherson
2022-08-03 15:08 ` Paolo Bonzini
2022-08-05 23:30 ` Vipin Sharma
2022-08-09 16:52 ` David Matlack
2022-08-09 23:51 ` Sean Christopherson [this message]
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=YvLzDUjpJHmZtn0i@google.com \
--to=seanjc@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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.