xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	adin@gridcentric.ca
Subject: Re: [PATCH 5 of 6] [RFC] x86/mm: use wait queues for mem_paging
Date: Mon, 27 Feb 2012 19:26:52 +0000	[thread overview]
Message-ID: <20120227192652.GC98737@ocelot.phlegethon.org> (raw)
In-Reply-To: <20120224134544.GA13134@aepfle.de>

Hi, 

At 14:45 +0100 on 24 Feb (1330094744), Olaf Hering wrote:
> >  #ifdef __x86_64__
> > +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> > +         && p2m->domain == current->domain ) 
> > +    {
> > +        if ( locked )
> > +            gfn_unlock(p2m, gfn, 0);
> > +
> > +        /* Ping the pager */
> > +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> > +            p2m_mem_paging_populate(p2m->domain, gfn);
> > +
> > +        /* Wait until the pager finishes paging it in */
> > +        current->arch.mem_paging_gfn = gfn;
> > +        wait_event(current->arch.mem_paging_wq, ({
> > +                    int done;
> > +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> > +                    done = (*t != p2m_ram_paging_in);
> 
> I assume p2m_mem_paging_populate() will not return until the state is
> forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
> more obvious what this check is supposed to do.

But it would be wrong.  If the type anything other than
p2m_ram_paging_in, then we can't be sure that the pager is working on
unblocking us.

Andres made the same suggestion - clearly this code needs a comment. :)

> > +                    /* Safety catch: it _should_ be safe to wait here
> > +                     * but if it's not, crash the VM, not the host */
> > +                    if ( in_atomic() )
> > +                    {
> > +                        WARN();
> > +                        domain_crash(p2m->domain);
> > +                        done = 1;
> > +                    }
> > +                    done;
> > +                }));
> > +        goto again;
> > +    }
> > +#endif

> >  void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >  {
> >      struct vcpu *v = current;
> > @@ -965,6 +1001,7 @@ void p2m_mem_paging_populate(struct doma
> >      p2m_access_t a;
> >      mfn_t mfn;
> >      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +    int send_request = 0;
> 
> Is that variable supposed to be used?

Erk.  Clearly something got mangled in the rebase.  I'll sort that out.

> Perhaps the feature to fast-forward (or rollback) from
> p2m_ram_paging_out to p2m_ram_rw could be a separate patch. My initial
> version of this patch did not have a strict requirement for this
> feature, if I remember correctly.

Sure, I can split that into a separate patch.

Cheers,

Tim.

  reply	other threads:[~2012-02-27 19:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 16:34 [PATCH 0 of 6] [RFC] Use wait queues for paging, v2 Tim Deegan
2012-02-23 16:34 ` [PATCH 1 of 6] mm: guest_remove_page() should not populate or unshare Tim Deegan
2012-02-23 16:34 ` [PATCH 2 of 6] x86/mm: remove 'p2m_guest' lookup type Tim Deegan
2012-02-23 16:34 ` [PATCH 3 of 6] x86/mm: make 'query type' argument to get_gfn into a set of flags Tim Deegan
2012-02-23 16:45   ` Andres Lagar-Cavilla
2012-02-23 16:34 ` [PATCH 4 of 6] x86/mm: tidy up get_two_gfns() a little Tim Deegan
2012-02-23 16:34 ` [PATCH 5 of 6] [RFC] x86/mm: use wait queues for mem_paging Tim Deegan
2012-02-24 13:45   ` Olaf Hering
2012-02-27 19:26     ` Tim Deegan [this message]
2012-02-27 20:18       ` Olaf Hering
2012-02-23 16:34 ` [PATCH 6 of 6] x86/mm: Don't claim a slot on the paging ring if we might not need it Tim Deegan
2012-02-23 16:48   ` Andres Lagar-Cavilla
2012-02-23 16:43 ` [PATCH 0 of 6] [RFC] Use wait queues for paging, v2 Tim Deegan
2012-02-23 16:49 ` Andres Lagar-Cavilla
2012-02-26 22:14 ` Olaf Hering
2012-02-27 16:51   ` Olaf Hering
     [not found]     ` <EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
2012-02-28 21:11       ` Andres Lagar-Cavilla
2012-02-29 16:18         ` Olaf Hering
2012-02-29 19:56           ` Olaf Hering
2012-03-15 15:27             ` Tim Deegan
2012-03-15 15:37               ` Olaf Hering
2012-03-15 15:40                 ` Tim Deegan
2012-03-15 15:56                   ` Andres Lagar-Cavilla

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=20120227192652.GC98737@ocelot.phlegethon.org \
    --to=tim@xen.org \
    --cc=adin@gridcentric.ca \
    --cc=andres@gridcentric.ca \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xensource.com \
    /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).