From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, maxime.coquelin@redhat.com, mst@redhat.com
Subject: Re: [Qemu-devel] [RFC 0/7] Rework vhost memory region updates
Date: Thu, 30 Nov 2017 13:06:29 +0000 [thread overview]
Message-ID: <20171130130628.GC3952@work-vm> (raw)
In-Reply-To: <20171130135820.69eb5715@redhat.com>
* Igor Mammedov (imammedo@redhat.com) wrote:
> On Thu, 30 Nov 2017 12:47:20 +0000
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
>
> > * Igor Mammedov (imammedo@redhat.com) wrote:
> > > On Thu, 30 Nov 2017 12:08:06 +0000
> > > "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> > >
> > > > * Igor Mammedov (imammedo@redhat.com) wrote:
> > > > > On Wed, 29 Nov 2017 18:50:19 +0000
> > > > > "Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> wrote:
> > > > >
> > > > > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > > > >
> > > > > > Hi,
> > > > > > This is an experimental set that reworks the way the vhost
> > > > > > code handles changes in physical address space layout that
> > > > > > came from a discussion with Igor.
> > > > > Thanks for looking into it.
> > > > >
> > > > >
> > > > > > Instead of updating and trying to merge sections of address
> > > > > > space on each add/remove callback, we wait until the commit phase
> > > > > > and go through and rebuild a list by walking the Flatview of
> > > > > > memory and end up producing an ordered list.
> > > > > > We compare the list to the old list to trigger updates.
> > > > > >
> > > > > > Note, only very lightly tested so far, I'm just trying to see if it's
> > > > > > the right shape.
> > > > > >
> > > > > > Igor, is this what you were intending?
> > > > >
> > > > > I was thinking about a little less intrusive approach
> > > > >
> > > > > where vhost_region_add/del are modified to maintain
> > > > > sorted by GPA array of mem_sections, vhost_dev::mem is dropped
> > > > > altogether and vhost_memory_region array is build/used/freed
> > > > > on every vhost_commit().
> > > > > Maintaining sorted array should roughly cost us O(2 log n) if
> > > > > binary search is used.
> > > > >
> > > > > However I like your idea with iterator even more as it have
> > > > > potential to make it even faster O(n) if we get rid of
> > > > > quadratic and relatively complex vhost_update_compare_list().
> > > >
> > > > Note vhost_update_compare_list is complex,
> > > > but it is O(n) - it's
> > > > got nested loops, but the inner loop moves forward and oldi never
> > > > gets reset back to zero.
> > > While skimming through patches I've overlooked it.
> > >
> > > Anyways,
> > > why memcmp(old_arr, new_arr) is not sufficient
> > > to detect a change in memory map?
> >
> > It tells you that you've got a change, but doesn't give
> > the start/end of the range that's changed, and those
> > are used by vhost_commit to limit the work of
> > vhost_verify_ring_mappings.
> Isn't memmap list a sorted and
> dev->mem_changed_[start|end]_addr are the lowest|highest
> addresses of whole map?
>
> If it's, so wouldn't getting values directly from
> the 1st/last entries of array be sufficient?
THat wasn't my understanding from the existing code;
my understanding was that changed_start_addr is set by
vhost_region_add->vhost_set_memory when a new region is added
(or removed) and is set to the limit of the section added.
But perhaps I'm misunderstanding.
(The logic in vhost_verify_ring_mappings doesn't make sense
to me either though; if vhost_verify_ring_part_mapping returns 0
on success, why is it doing if (!r) { break; } surely it
should be if (r) { break; })
Dave
>
>
> >
> > Dave
> >
> > > >
> > > > > Pls, see comments on individual patches.
> > > >
> > > > Thanks; I have fixed a couple of bugs since I posted, so I'm
> > > > more interested in structure/shape. Any good ideas how to test
> > > > it are welcome.
> > > >
> > > > Dave
> > > >
> > > > >
> > > > > > Dave
> > > > > >
> > > > > > Dr. David Alan Gilbert (7):
> > > > > > memory: address_space_iterate
> > > > > > vhost: Move log_dirty check
> > > > > > vhost: New memory update functions
> > > > > > vhost: update_mem_cb implementation
> > > > > > vhost: Compare new and old memory lists
> > > > > > vhost: Copy updated region data into device state
> > > > > > vhost: Remove vhost_set_memory and children
> > > > > >
> > > > > > hw/virtio/trace-events | 8 +
> > > > > > hw/virtio/vhost.c | 424 ++++++++++++++++++++++---------------------------
> > > > > > include/exec/memory.h | 23 +++
> > > > > > memory.c | 22 +++
> > > > > > 4 files changed, 241 insertions(+), 236 deletions(-)
> > > > > >
> > > > >
> > > > --
> > > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > >
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2017-11-30 13:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 18:50 [Qemu-devel] [RFC 0/7] Rework vhost memory region updates Dr. David Alan Gilbert (git)
2017-11-29 18:50 ` [Qemu-devel] [RFC 1/7] memory: address_space_iterate Dr. David Alan Gilbert (git)
2017-11-29 18:50 ` [Qemu-devel] [RFC 2/7] vhost: Move log_dirty check Dr. David Alan Gilbert (git)
2017-11-29 18:50 ` [Qemu-devel] [RFC 3/7] vhost: New memory update functions Dr. David Alan Gilbert (git)
2017-11-30 15:48 ` Igor Mammedov
2017-12-05 18:25 ` Dr. David Alan Gilbert
2017-11-29 18:50 ` [Qemu-devel] [RFC 4/7] vhost: update_mem_cb implementation Dr. David Alan Gilbert (git)
2017-11-30 11:27 ` Igor Mammedov
2017-12-06 20:09 ` Dr. David Alan Gilbert
2017-11-29 18:50 ` [Qemu-devel] [RFC 5/7] vhost: Compare new and old memory lists Dr. David Alan Gilbert (git)
2017-11-29 18:50 ` [Qemu-devel] [RFC 6/7] vhost: Copy updated region data into device state Dr. David Alan Gilbert (git)
2017-11-29 18:50 ` [Qemu-devel] [RFC 7/7] vhost: Remove vhost_set_memory and children Dr. David Alan Gilbert (git)
2017-11-30 11:22 ` [Qemu-devel] [RFC 0/7] Rework vhost memory region updates Igor Mammedov
2017-11-30 12:08 ` Dr. David Alan Gilbert
2017-11-30 12:40 ` Igor Mammedov
2017-11-30 12:47 ` Dr. David Alan Gilbert
2017-11-30 12:58 ` Igor Mammedov
2017-11-30 13:06 ` Dr. David Alan Gilbert [this message]
2017-11-30 15:08 ` Igor Mammedov
2017-11-30 15:18 ` Dr. David Alan Gilbert
2017-11-30 15:32 ` Igor Mammedov
2017-11-30 15:41 ` Dr. David Alan Gilbert
2017-11-30 16:51 ` Greg Kurz
2017-12-01 10:02 ` Stefan Hajnoczi
2017-12-01 10:19 ` Dr. David Alan Gilbert
2017-12-01 14:22 ` [Qemu-devel] [RFC] vhost: check if ring mapping is still valid when building memmap Igor Mammedov
2017-12-07 18:17 ` Dr. David Alan Gilbert
2017-12-08 14:42 ` Igor Mammedov
2017-12-08 17:51 ` Dr. David Alan Gilbert
2017-12-11 9:37 ` Igor Mammedov
2017-12-11 11:03 ` Dr. David Alan Gilbert
2017-12-11 13:45 ` Igor Mammedov
2017-12-11 15:43 ` Dr. David Alan Gilbert
2017-12-08 20:45 ` Dr. David Alan Gilbert
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=20171130130628.GC3952@work-vm \
--to=dgilbert@redhat.com \
--cc=imammedo@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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).