From: Gleb Natapov <gleb@redhat.com>
To: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Cc: Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH 7/8] KVM: make async_pf work queue lockless
Date: Thu, 28 Oct 2010 11:14:50 +0200 [thread overview]
Message-ID: <20101028091450.GT26191@redhat.com> (raw)
In-Reply-To: <4CC93DAA.2070406@cn.fujitsu.com>
On Thu, Oct 28, 2010 at 05:08:58PM +0800, Xiao Guangrong wrote:
> On 10/27/2010 07:41 PM, Gleb Natapov wrote:
> > On Wed, Oct 27, 2010 at 05:09:41PM +0800, Xiao Guangrong wrote:
> >> The async_pf number is very few since only pending interrupt can
> >> let it re-enter to the guest mode.
> >>
> >> During my test(Host 4 CPU + 4G, Guest 4 VCPU + 6G), it's no
> >> more than 10 requests in the system.
> >>
> >> So, we can only increase the completion counter in the work queue
> >> context, and walk vcpu->async_pf.queue list to get all completed
> >> async_pf
> >>
> > That depends on the load. I used memory cgroups to create very big
> > memory pressure and I saw hundreds of apfs per second. We shouldn't
> > optimize for very low numbers. With vcpu->async_pf.queue having more
> > then one element I am not sure your patch is beneficial.
> >
>
> Maybe we need a new no-lock way to record the complete apfs, i'll reproduce
> your test environment and improve it.
>
That is always welcomed :)
> >> +
> >> + list_del(&work->queue);
> >> + vcpu->async_pf.queued--;
> >> + kmem_cache_free(async_pf_cache, work);
> >> + if (atomic_dec_and_test(&vcpu->async_pf.done))
> >> + break;
> > You should do atomic_dec() and always break. We cannot inject two apfs during
> > one vcpu entry.
> >
>
> Sorry, i'm little confused.
>
> Why 'atomic_dec_and_test(&vcpu->async_pf.done)' always break? async_pf.done is used to
In your code it is not, but it should (at least if guest is PV, read
below).
> record the complete apfs and many apfs may be completed when vcpu enters guest mode(it
> means vcpu->async_pf.done > 1)
>
Correct, but only one apf should be handled on each vcpu entry in case
of PV guest. Look at kvm_arch_async_page_present(vcpu, work); that is called
in a loop in your code. If vcpu->arch.apf.msr_val & KVM_ASYNC_PF_ENABLED
is not null it injects exception into the guest. You can't inject more
then one exception on each guest entry. If guest is not PV you are
correct that we can loop here until vcpu->async_pf.done == 0.
> Look at the current code:
>
> void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu)
> {
> ......
> spin_lock(&vcpu->async_pf.lock);
> work = list_first_entry(&vcpu->async_pf.done, typeof(*work), link);
> list_del(&work->link);
> spin_unlock(&vcpu->async_pf.lock);
> ......
> }
>
> You only handle one complete apf, why we inject them at once? I missed something? :-(
--
Gleb.
next prev parent reply other threads:[~2010-10-28 9:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-27 9:01 [PATCH 1/8] KVM: fix tracing kvm_try_async_get_page Xiao Guangrong
2010-10-27 9:02 ` [PATCH 2/8] KVM: cleanup aysnc_pf tracepoints Xiao Guangrong
2010-10-27 10:10 ` Gleb Natapov
2010-10-27 9:03 ` [PATCH 3/8] KVM: fix searching async gfn in kvm_async_pf_gfn_slot Xiao Guangrong
2010-10-27 10:29 ` Gleb Natapov
2010-10-27 9:04 ` [PATCH 4/8] KVM: avoid unnecessary wait for a async pf Xiao Guangrong
2010-10-27 10:42 ` Gleb Natapov
2010-10-28 7:06 ` Xiao Guangrong
2010-10-27 9:05 ` [PATCH 5/8] KVM: don't touch vcpu stat after async pf is complete Xiao Guangrong
2010-10-27 10:44 ` Gleb Natapov
2010-10-28 7:35 ` Xiao Guangrong
2010-10-28 7:41 ` Gleb Natapov
2010-10-27 9:07 ` [PATCH 6/8] KVM: simply wakup async pf Xiao Guangrong
2010-10-27 10:50 ` Gleb Natapov
2010-10-28 7:59 ` Xiao Guangrong
2010-10-27 9:09 ` [PATCH 7/8] KVM: make async_pf work queue lockless Xiao Guangrong
2010-10-27 11:41 ` Gleb Natapov
2010-10-28 9:08 ` Xiao Guangrong
2010-10-28 9:14 ` Gleb Natapov [this message]
2010-10-27 9:10 ` [PATCH 8/8] KVM: add debugfs file to show the number of async pf Xiao Guangrong
2010-10-27 10:58 ` Gleb Natapov
2010-10-28 9:09 ` Xiao Guangrong
2010-10-27 9:59 ` [PATCH 1/8] KVM: fix tracing kvm_try_async_get_page Gleb Natapov
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=20101028091450.GT26191@redhat.com \
--to=gleb@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=xiaoguangrong@cn.fujitsu.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