All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, KVM list <kvm@vger.kernel.org>
Subject: Re: unit tests and get_user_pages_ptes_fast()
Date: Tue, 05 Oct 2010 16:36:26 +0200	[thread overview]
Message-ID: <4CAB37EA.9030108@redhat.com> (raw)
In-Reply-To: <20101005143246.GW26357@random.random>

  On 10/05/2010 04:32 PM, Andrea Arcangeli wrote:
> On Tue, Oct 05, 2010 at 04:25:05PM +0200, Avi Kivity wrote:
> >    On 10/05/2010 04:15 PM, Andrea Arcangeli wrote:
> >  >  On Tue, Oct 05, 2010 at 06:22:17AM -0300, Marcelo Tosatti wrote:
> >  >  >   It'll not be so advantageous for ksm because there should be read-faults
> >  >  >   very rarely on that case.
> >  >
> >  >  It'll also make all clean swapcache dirty for no good.
> >  >
> >  >  >   Will post.
> >  >
> >  >  If we've to walk pagetables twice, why don't you do this:
> >  >
> >  >  writable=1
> >  >  get_user_pages_fast(write=write_fault)
> >  >  if (!write_fault)
> >  >      writable = __get_user_pages_fast(write=1)
> >  >
> >  >  That will solve the debugging knob and it'll solve ksm and it'll be
> >  >  optimal for read swapins on exclusive clean swapcache too.
> >
> >  But it means an extra vmexit in the following case:
> >
> >  - read fault
> >  - page is present and writeable in the Linux page table
> >
> >  which is very common.  For this you need get_user_pages_ptes_fast().
>
> With a read fault, the VM already sets the pte as writable if the VM
> permissions allows that and the page isn't shared (i.e. if it's an
> exclusive swap page). We've just to check if it did that or not. So
> when it's a read fault we've to run __get_user_pages_fast(write=1)
> before we can assume the page is mapped writable in the pte.
>
> So I don't see the problem... in terms of page faults is optimal. Only
> downside is having to walk the pagetables twice, the second time to
> verify if the first gup_fast has marked the host pte writable or not.

You're right, I misread your pseudocode.

-- 
error compiling committee.c: too many arguments to function


      reply	other threads:[~2010-10-05 14:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-04  9:35 unit tests and get_user_pages_ptes_fast() Avi Kivity
2010-10-04 13:40 ` Andrea Arcangeli
2010-10-04 23:59   ` Marcelo Tosatti
2010-10-05  7:36     ` Avi Kivity
2010-10-05  9:22       ` Marcelo Tosatti
2010-10-05 14:15         ` Andrea Arcangeli
2010-10-05 14:25           ` Avi Kivity
2010-10-05 14:32             ` Andrea Arcangeli
2010-10-05 14:36               ` Avi Kivity [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=4CAB37EA.9030108@redhat.com \
    --to=avi@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.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.