qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 37/47] Page request: Consume pages off the po


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v4 37/47] Page request: Consume pages off the post-copy queue
Date: Wed, 14 Jan 2015 20:13:27 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

* David Gibson (address@hidden) wrote:
> On Fri, Oct 03, 2014 at 06:47:43PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > When transmitting RAM pages, consume pages that have been queued by
> > MIG_RPCOMM_REQPAGE commands and send them ahead of normal page scanning.
> > 
> > Note:
> >   a) After a queued page the linear walk carries on from after the
> > unqueued page; there is a reasonable chance that the destination
> > was about to ask for other closeby pages anyway.
> > 
> >   b) We have to be careful of any assumptions that the page walking
> > code makes, in particular it does some short cuts on its first linear
> > walk that break as soon as we do a queued page.
> > 
> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > ---
> >  arch_init.c | 149 
> > ++++++++++++++++++++++++++++++++++++++++++++++++++----------
> >  1 file changed, 125 insertions(+), 24 deletions(-)
> > 
> > diff --git a/arch_init.c b/arch_init.c
> > index 72f9e17..a945990 100644
> > +
> > +        /*
> > +         * Don't break host-page chunks up with queue items
> 
> Why does this matter?

See the comment you make in a few patches time, it's about being able
to place the pages atomically on the destination.

> > +         * so only unqueue if,
> > +         *   a) The last item came from the queue anyway
> > +         *   b) The last sent item was the last target-page in a host page
> > +         */
> > +        if (last_was_from_queue || (!last_sent_block) ||
> > +            ((last_offset & (hps - 1)) == (hps - TARGET_PAGE_SIZE))) {
> > +            tmpblock = ram_save_unqueue_page(ms, &tmpoffset, &bitoffset);
> >          }
> > -        if (offset >= block->length) {
> > -            offset = 0;
> > -            block = QTAILQ_NEXT(block, next);
> > -            if (!block) {
> > -                block = QTAILQ_FIRST(&ram_list.blocks);
> > -                complete_round = true;
> > -                ram_bulk_stage = false;
> > +
> > +        if (tmpblock) {
> > +            /* We've got a block from the postcopy queue */
> > +            DPRINTF("%s: Got postcopy item '%s' offset=%zx bitoffset=%zx",
> > +                    __func__, tmpblock->idstr, tmpoffset, bitoffset);
> > +            /* We're sending this page, and since it's postcopy nothing 
> > else
> > +             * will dirty it, and we must make sure it doesn't get sent 
> > again.
> > +             */
> > +            if (!migration_bitmap_clear_dirty(bitoffset << 
> > TARGET_PAGE_BITS)) {
> 
> Ugh.. that's kind of subtle.  I think it would be clearer if you work
> in terms of a ram_addr_t throughout, rather than "bitoffset" whose
> meaning is not terribly obvious.

I've changed it to ram_addr_t as requested; it's slightly clearer but there
are a few places where we're dealing with the sentmap where we now need to shift
the other way.  In the end ram_addr_t is really a scaled offset into those
bitmaps.

Dave

> 
> -- 
> David Gibson                  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au        | minimalist, thank you.  NOT _the_ 
> _other_
>                               | _way_ _around_!
> http://www.ozlabs.org/~dgibson


--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]