public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: <xen-devel@lists.xen.org>, <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] grant-table: don't set m2p override if kmap_ops is not set
Date: Tue, 5 Nov 2013 15:47:08 +0100	[thread overview]
Message-ID: <527904EC.9090402@citrix.com> (raw)
In-Reply-To: <5278E64C.40200@citrix.com>

On 05/11/13 13:36, David Vrabel wrote:
> On 05/11/13 11:24, Roger Pau Monne wrote:
>> IMHO there's no reason to set a m2p override if the mapping is done in
>> kernel space, so only set the m2p override when kmap_ops is set.
> 
> Can you provide a more detailed reasoning about why this is safe?

To tell the truth, I don't understand why we need to use the m2p
override for kernel space only mappings, my understanding is that this
m2p override is needed for user space mappings only (where we actually
end up doing two mappings, one in kernel space and one in user space).
For kernel space I don't see why we need to do anything else than
setting the right p2m translation.

> Did you consider other ways of improving scalability?  e.g., a
> per-bucket read-write lock.

Not really, the main focus of this patch is to optimize kernel space
only mappings (like the ones done in blkback), so why go down this road
when we can actually remove the need for a lock at all in this case?

  reply	other threads:[~2013-11-05 14:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 11:24 [PATCH] grant-table: don't set m2p override if kmap_ops is not set Roger Pau Monne
2013-11-05 11:26 ` Roger Pau Monné
2013-11-05 12:36 ` David Vrabel
2013-11-05 14:47   ` Roger Pau Monné [this message]
2013-11-05 14:56     ` Konrad Rzeszutek Wilk
2013-11-05 15:01       ` Roger Pau Monné
2013-11-05 15:08         ` [Xen-devel] " Ian Campbell
2013-11-05 16:03           ` Roger Pau Monné
2013-11-05 20:06             ` Matt Wilson
2013-11-05 20:53               ` Anthony Liguori
2013-11-05 21:16                 ` Konrad Rzeszutek Wilk
2013-11-05 22:09                   ` Anthony Liguori
2013-11-05 22:19                     ` Matt Wilson
2013-11-06 10:22                 ` Ian Campbell
2013-11-06 18:46                   ` Anthony Liguori
2013-11-06 11:34                 ` David Vrabel
2013-11-06 17:59                   ` Matt Wilson
2013-11-06 18:52                     ` Konrad Rzeszutek Wilk
2013-11-07 20:15                       ` Stefano Stabellini

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=527904EC.9090402@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msw@amazon.com \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox