All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: kvm-ppc@vger.kernel.org
Subject: Re: [PATCH v5 5/5] KVM: PPC: e500: MMU API
Date: Mon, 08 Aug 2011 08:49:36 +0000	[thread overview]
Message-ID: <20110808084936.GD27011@cmpxchg.org> (raw)
In-Reply-To: <20110707234159.GE6646@schlenkerla.am.freescale.net>

On Mon, Jul 25, 2011 at 11:50:50PM +0200, Alexander Graf wrote:
> 
> On 25.07.2011, at 21:25, Scott Wood wrote:
> 
> > On Sun, 24 Jul 2011 11:16:32 +0200
> > Alexander Graf <agraf@suse.de> wrote:
> > 
> >> On 19.07.2011, at 13:20, Johannes Weiner wrote:
> >> 
> >>> You don't have to work around the mm subsystem trying to reclaim your
> >>> memory,
> > 
> > The pages are pinned by get_free_pages_fast().
> > 
> >>> maintain disk coherency that is guaranteed by the filebacked
> >>> memory semantics etc.
> >>> 
> >>> If your driver provides the memory, there are much less assumptions
> >>> from userspace that you have to consider and memory management will
> >>> not interfere either.
> >> 
> >> Ah, thanks a lot. Scott, mind to switch this to the normal scheme then? Sounds like we don't need to dirty set by then either.
> > 
> > That's a fair bit of churn and added complexity, both here and in qemu.  Is
> > it really worth redesigning this API again, to avoid setting a few dirty
> > bits on an already-slow heavyweight exit?
> 
> Well, alternatively we could simply bail out if the memory is not
> anonymous, right? Then the pinning on get_user_pages_fast should be
> enough. Johannes, would there be any downside to this approach?

I don't see any correctness issues.  Maybe Andrea does?

While the userspace pages are never freed because of your reference,
it does not prevent reclaim from writing them to swap und unmapping
them from the user's page tables.

So even if it's working, it's still a bit of a hack...

  parent reply	other threads:[~2011-08-08  8:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-07 23:41 [PATCH v5 5/5] KVM: PPC: e500: MMU API Scott Wood
2011-07-08 12:57 ` Alexander Graf
2011-07-18 10:09 ` Alexander Graf
2011-07-18 16:18 ` Scott Wood
2011-07-18 16:33 ` Alexander Graf
2011-07-18 18:08 ` Scott Wood
2011-07-18 21:44 ` Alexander Graf
2011-07-19  8:36 ` Johannes Weiner
2011-07-19  8:51 ` Alexander Graf
2011-07-19 11:20 ` Johannes Weiner
2011-07-24  9:16 ` Alexander Graf
2011-07-25 19:25 ` Scott Wood
2011-07-25 21:50 ` Alexander Graf
2011-08-08  8:49 ` Johannes Weiner [this message]
2011-08-08 23:13 ` Scott Wood
2011-08-13 15:14 ` Benjamin Herrenschmidt
2011-08-15 15:03 ` Scott Wood
2011-08-15 15:15 ` Benjamin Herrenschmidt
2011-08-15 20:55 ` Scott Wood

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=20110808084936.GD27011@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=kvm-ppc@vger.kernel.org \
    /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.