DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] dpdk/vhost-user and VM migration
Date: Wed, 14 Oct 2015 00:16:29 +0300	[thread overview]
Message-ID: <20151014000508-mutt-send-email-mst@redhat.com> (raw)

Hello!
I am currently looking at how using dpdk on host, accessing VM memory
using the vhost-user interface, interacts with VM migration.

The issue is that any changes made to VM memory need to be tracked so
that updates can be sent from migration source to destination.

At the moment, there's a proposal of an interface extension to
vhost-user which adds ability to do this tracking through shared memory.
dpdk would then be responsible for tracking these updates using atomic
operations to set bits (per page written) in a memory bitmap.

This only needs to happen during migration, at other times there could
be a jump to skip this logging.

Is this a reasonable approach? Would performance degradation during
migration associated with atomics affect the performance to a level
where it's no longer useful?  Pls note these logs aren't latency
sensitive, so can be done on a separate core, and can be batched.


One alternative I'm considering is extending linux kernel so it can do
this tracking automatically, by marking pages read-only, detecting a
pagefault and logging the write, then making the pages writeable.  This
would mean higher worst-case overhead (pagefaults are expensive) but
lower average one (not extra code after the first fault).  Not sure how
feasible this is yet, this would be harder to implement and it will only
be apply to newer host kernels.

Any feedback would be appreciated.

-- 
MST

             reply	other threads:[~2015-10-13 21:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-13 21:16 Michael S. Tsirkin [this message]
2015-10-16  7:37 ` Yuanhan Liu
2015-10-28  9:52   ` Amnon Ilan
2015-10-28 12:30     ` Yuanhan Liu

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=20151014000508-mutt-send-email-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=dev@dpdk.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;
as well as URLs for NNTP newsgroup(s).