public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Nikita Kalyazin <kalyazin@amazon.com>
Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de,  dave.hansen@linux.intel.com, hpa@zytor.com,
	kvm@vger.kernel.org,  linux-kernel@vger.kernel.org,
	david@redhat.com, peterx@redhat.com,  oleg@redhat.com,
	vkuznets@redhat.com, gshan@redhat.com, graf@amazon.de,
	 jgowans@amazon.com, roypat@amazon.co.uk, derekmn@amazon.com,
	nsaenz@amazon.es,  xmarcalx@amazon.com
Subject: Re: [PATCH] KVM: x86: async_pf: check earlier if can deliver async pf
Date: Tue, 19 Nov 2024 05:24:01 -0800	[thread overview]
Message-ID: <ZzyRcQmxA3SiEHXT@google.com> (raw)
In-Reply-To: <20241118130403.23184-1-kalyazin@amazon.com>

On Mon, Nov 18, 2024, Nikita Kalyazin wrote:
> On x86, async pagefault events can only be delivered if the page fault
> was triggered by guest userspace, not kernel.  This is because
> the guest may be in non-sleepable context and will not be able
> to reschedule.
> 
> However existing implementation pays the following overhead even for the
> kernel-originated faults, even though it is known in advance that they
> cannot be processed asynchronously:
>  - allocate async PF token
>  - create and schedule an async work

Very deliberately, because as noted below, async page faults aren't limited to
the paravirt case.

> This patch avoids the overhead above in case of kernel-originated faults

Please avoid "This patch".

> by moving the `kvm_can_deliver_async_pf` check from
> `kvm_arch_async_page_not_present` to `__kvm_faultin_pfn`.
> 
> Note that the existing check `kvm_can_do_async_pf` already calls
> `kvm_can_deliver_async_pf` internally, however it only does that if the
> `kvm_hlt_in_guest` check is true, ie userspace requested KVM not to exit
> on guest halts via `KVM_CAP_X86_DISABLE_EXITS`.  In that case the code
> proceeds with the async fault processing with the following
> justification in 1dfdb45ec510ba27e366878f97484e9c9e728902 ("KVM: x86:
> clean up conditions for asynchronous page fault handling"):
> 
> "Even when asynchronous page fault is disabled, KVM does not want to pause
> the host if a guest triggers a page fault; instead it will put it into
> an artificial HLT state that allows running other host processes while
> allowing interrupt delivery into the guest."

None of this justifies breaking host-side, non-paravirt async page faults.  If a
vCPU hits a missing page, KVM can schedule out the vCPU and let something else
run on the pCPU, or enter idle and let the SMT sibling get more cycles, or maybe
even enter a low enough sleep state to let other cores turbo a wee bit.

I have no objection to disabling host async page faults, e.g. it's probably a net
negative for 1:1 vCPU:pCPU pinned setups, but such disabling needs an opt-in from
userspace.

  parent reply	other threads:[~2024-11-19 13:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18 13:04 [PATCH] KVM: x86: async_pf: check earlier if can deliver async pf Nikita Kalyazin
2024-11-18 17:58 ` Vitaly Kuznetsov
2024-11-21 18:10   ` Nikita Kalyazin
2024-11-22  9:33     ` Vitaly Kuznetsov
2024-11-22 14:32       ` Sean Christopherson
2024-11-19 13:24 ` Sean Christopherson [this message]
2024-11-21 17:59   ` Nikita Kalyazin
2024-11-21 21:05     ` Sean Christopherson
2024-11-25 15:50       ` Nikita Kalyazin
2024-11-26  0:06         ` Sean Christopherson
2024-11-26 15:35           ` Nikita Kalyazin
2024-11-26 22:10             ` Sean Christopherson
2024-11-27 10:35               ` Nikita Kalyazin

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=ZzyRcQmxA3SiEHXT@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=derekmn@amazon.com \
    --cc=graf@amazon.de \
    --cc=gshan@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jgowans@amazon.com \
    --cc=kalyazin@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nsaenz@amazon.es \
    --cc=oleg@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=roypat@amazon.co.uk \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=xmarcalx@amazon.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox