From: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Avi Kivity <avi@redhat.com>,
mtosatti@redhat.com, kvm@vger.kernel.org,
yoshikawa.takuya@oss.ntt.co.jp
Subject: Re: [RFC PATCH 3/3] KVM: MMU: Optimize guest page table walk
Date: Fri, 29 Apr 2011 22:51:48 +0900 [thread overview]
Message-ID: <20110429225148.49e6e700.takuya.yoshikawa@gmail.com> (raw)
In-Reply-To: <20110429065956.GA3985@one.firstfloor.org>
Andi Kleen <andi@firstfloor.org> wrote:
> > Only I can guess for that reason is the reduction of some function calls
> > by inlining some functions.
>
> Yes once at a time cfu was inline too and just checked for the right
> sizes and the used g*u, but it got lost in the "icache over everything else" mania which is unfortunately en vogue for quite some time in kernel land (aka
> measuring patches only based on their impact on the .text
> size, not the actual performance)
>
> But you might getter better gains by fixing this general
> c*u() regression.
>
What I mentioned was about not only cfu but 3 functions.
Originally, we were doing the following function calls:
walk_addr_generic() ---1
kvm_read_guest_page_mmu() ---2
kvm_read_guest_page() ---3
copy_from_user() ---4
And now, with my patch already applied, we are not using
generic kvm_read_guest_page_mmu() and some address
calculations are done in walk_addr_generic():
walk_addr_generic() ---1'
get_user() ---2'
The length is passed in from walk_addr_generic().
Do you think the following case would not differ so much
from (1' 2') ?
walk_addr_generic() ---1''
copy_from_user() ---2''
This can satisfy your "assuming you pass in a constant length"
and almost same as get_user() ?
Takuya
next prev parent reply other threads:[~2011-04-29 13:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 18:32 [PATCH 1/3] KVM: Introduce a helper to check if gfn is in memslot Takuya Yoshikawa
2011-04-18 18:34 ` [PATCH 2/3] KVM: MMU: Introduce a helper to read guest pte Takuya Yoshikawa
2011-04-20 9:07 ` Avi Kivity
2011-04-20 9:35 ` Roedel, Joerg
2011-04-20 10:05 ` Avi Kivity
2011-04-20 11:06 ` Roedel, Joerg
2011-04-20 11:18 ` Avi Kivity
2011-04-20 13:33 ` [PATCH] KVM: MMU: Make cmpxchg_gpte aware of nesting too Roedel, Joerg
2011-04-21 1:02 ` Takuya Yoshikawa
2011-04-21 8:11 ` Avi Kivity
2011-04-21 1:07 ` [PATCH 2/3] KVM: MMU: Introduce a helper to read guest pte Takuya Yoshikawa
2011-04-18 18:38 ` [RFC PATCH 3/3] KVM: MMU: Optimize guest page table walk Takuya Yoshikawa
2011-04-18 18:52 ` Joerg Roedel
2011-04-19 1:24 ` Takuya Yoshikawa
2011-04-19 6:20 ` Joerg Roedel
2011-04-19 1:42 ` Xiao Guangrong
2011-04-19 3:47 ` Takuya Yoshikawa
2011-04-20 9:09 ` Avi Kivity
2011-04-20 9:02 ` Avi Kivity
2011-04-29 2:46 ` Andi Kleen
2011-04-29 5:38 ` Takuya Yoshikawa
2011-04-29 6:30 ` Takuya Yoshikawa
2011-04-29 6:59 ` Andi Kleen
2011-04-29 13:51 ` Takuya Yoshikawa [this message]
2011-04-29 16:05 ` Andi Kleen
2011-05-01 13:32 ` Avi Kivity
2011-05-01 20:51 ` Andi Kleen
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=20110429225148.49e6e700.takuya.yoshikawa@gmail.com \
--to=takuya.yoshikawa@gmail.com \
--cc=andi@firstfloor.org \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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;
as well as URLs for NNTP newsgroup(s).