mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: lguest <lguest@ozlabs.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] lguest: use get_user_pages_fast() instead of get_user_pages()
Date: Wed, 30 Jul 2008 15:30:10 +1000	[thread overview]
Message-ID: <200807301530.10205.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <200807301439.47856.rusty@rustcorp.com.au>

On Wednesday 30 July 2008 14:39, Rusty Russell wrote:
> Using a simple page table thrashing program I measure a slight
> improvement.  The program creates five processes.  Each touches 1000
> pages then schedules the next process.  We repeat this 1000 times.  As
> lguest only caches 4 cr3 values, this rebuilds a lot of shadow page
> tables requiring virt->phys mappings.
>
> 	Before: 5.93 seconds
> 	After: 5.40 seconds
>
> (Counts of slow vs fastpath in this usage are 6092 and 2852462
> respectively.)
>
> And more importantly for lguest, the code is simpler.

Cool. That's actually a fairly significant straight-line performance
improvement, given that the lguest processes are running one-at-a-time
right? (and not contending on the locks or bouncing cachelines too much)

Nice.

>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> ---
>  drivers/lguest/page_tables.c |   25 +++++++++----------------
>  1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff -r cb465381f6d5 drivers/lguest/page_tables.c
> --- a/drivers/lguest/page_tables.c	Wed Jul 30 10:18:44 2008 +1000
> +++ b/drivers/lguest/page_tables.c	Wed Jul 30 12:11:42 2008 +1000
> @@ -108,9 +108,8 @@ static unsigned long gpte_addr(pgd_t gpg
>  }
>  /*:*/
>
> -/*M:014 get_pfn is slow; it takes the mmap sem and calls get_user_pages. 
> We - * could probably try to grab batches of pages here as an optimization
> - * (ie. pre-faulting). :*/
> +/*M:014 get_pfn is slow: we could probably try to grab batches of pages
> here as + * an optimization (ie. pre-faulting). :*/
>
>  /*H:350 This routine takes a page number given by the Guest and converts
> it to * an actual, physical page number.  It can fail for several reasons:
> the @@ -123,19 +122,13 @@ static unsigned long get_pfn(unsigned lo
>  static unsigned long get_pfn(unsigned long virtpfn, int write)
>  {
>  	struct page *page;
> +
> +	/* gup me one page at this address please! */
> +	if (get_user_pages_fast(virtpfn << PAGE_SHIFT, 1, write, &page) == 1)
> +		return page_to_pfn(page);
> +
>  	/* This value indicates failure. */
> -	unsigned long ret = -1UL;
> -
> -	/* get_user_pages() is a complex interface: it gets the "struct
> -	 * vm_area_struct" and "struct page" assocated with a range of pages.
> -	 * It also needs the task's mmap_sem held, and is not very quick.
> -	 * It returns the number of pages it got. */
> -	down_read(&current->mm->mmap_sem);
> -	if (get_user_pages(current, current->mm, virtpfn << PAGE_SHIFT,
> -			   1, write, 1, &page, NULL) == 1)
> -		ret = page_to_pfn(page);
> -	up_read(&current->mm->mmap_sem);
> -	return ret;
> +	return -1UL;
>  }
>
>  /*H:340 Converting a Guest page table entry to a shadow (ie. real) page
> table @@ -174,7 +167,7 @@ static pte_t gpte_to_spte(struct lg_cpu
>  /*H:460 And to complete the chain, release_pte() looks like this: */
>  static void release_pte(pte_t pte)
>  {
> -	/* Remember that get_user_pages() took a reference to the page, in
> +	/* Remember that get_user_pages_fast() took a reference to the page, in
>  	 * get_pfn()?  We have to put it back now. */
>  	if (pte_flags(pte) & _PAGE_PRESENT)
>  		put_page(pfn_to_page(pte_pfn(pte)));

  reply	other threads:[~2008-07-30  5:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-30  4:38 [PATCH 1/2] Export get_user_pages_fast Rusty Russell
2008-07-30  4:39 ` [PATCH 2/2] lguest: use get_user_pages_fast() instead of get_user_pages() Rusty Russell
2008-07-30  5:30   ` Nick Piggin [this message]
2008-07-30  6:53     ` Rusty Russell
2008-07-30  5:23 ` [PATCH 1/2] Export get_user_pages_fast Nick Piggin
2008-07-30 10:35 ` Andrew Morton
2008-07-30 15:47   ` Adrian Bunk
2008-07-30 17:03     ` Andrew Morton
2008-07-30 17:09       ` Adrian Bunk
2008-07-30 17:14         ` Andrew Morton
2008-07-30 17:18           ` Adrian Bunk
2008-07-30 17:28             ` Andrew Morton
2008-07-30 17:39               ` Adrian Bunk
2008-07-30 17:50                 ` Andrew Morton
2008-07-30 17:23           ` Avi Kivity
2008-07-30 17:29             ` Andrew Morton
2008-07-31  6:43               ` Avi Kivity
2008-07-31  7:02                 ` Andrew Morton
2008-07-31  8:10                   ` Nick Piggin
2008-07-31  8:21                     ` Andrew Morton
2008-07-31  8:32                       ` Benjamin Herrenschmidt
2008-07-31  8:48                       ` Nick Piggin
2008-07-31  8:52                         ` Benjamin Herrenschmidt
2008-07-31  8:56                           ` Nick Piggin
2008-08-05  5:47                             ` Rusty Russell

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=200807301530.10205.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=lguest@ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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

all inboxes | Powered by JetHome®