All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Xen Developer Summit Storage Performance BoF notes
Date: Wed, 30 Oct 2013 11:03:54 +0000	[thread overview]
Message-ID: <5270E79A.1050703@citrix.com> (raw)

[ I forgot to make notes so these are from memory, please respond with
any corrections or omissions. ]

Felipe introduced the session, highlighting the change in storage (i.e.,
low latency SSDs and fast SANs) were exposing bottlenecks in the current
architecture which is designed with slow disks.  Refer to his
presentation from Friday for more details.

Felipe noted that persistent grants were causing performance regressions
when the backend did not support them and system where copy cost > map
cost (e.g., when dom0 has few VCPUs).  Roger agreed on restoring the
zero-copy path in the frontends was a good idea. [He has now posted
patches for this.]

Felipe mentioned that persistent grants were most beneficial when using
user space backend.  David pointed out that this is most likely caused
by a poor implementation of the gntdev device.

Matt mentioned contention on the m2p override lock as causing
performance problems and suggested making this a read/write lock.

David listed some of the key bottlenecks already identified and plans to
resolve them without any protocol changes.

1. Unmap TLB flushes can be eliminated if the mapping is not used.
Experiments by XenServer suggest grant mapped pages by blkback are never
accessed thus eliminating all TLB flushes.

2. Grant table lock contention can be reduced by finer grained locked.
e.g., by having buckets of map tracking structures and hashing
domid+grant ref to a bucket.

3. gntdev device does a double map/unmap (for userspace and kernel
mapping) and does the kernel mapping a page at a time.  Userspace
mappings could be done at page fault time (in the expectation that
userspace doesn't touch them) and the kernel side should batch grant
table ops using a new GNTOP_unmap_and_duplicate hypercall sub-op for the
unmap.  Roger said he'd posted patch for the sub-op, but received no
feedback.

Anil mentioned PV filesystems but this wasn't discussed in any depth.

             reply	other threads:[~2013-10-30 11:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-30 11:03 David Vrabel [this message]
2013-10-30 11:33 ` Xen Developer Summit Storage Performance BoF notes Roger Pau Monné
2013-10-30 18:20   ` Konrad Rzeszutek Wilk
2013-10-30 16:09 ` Felipe Franciosi

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=5270E79A.1050703@citrix.com \
    --to=david.vrabel@citrix.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 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.