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.
next prev parent 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).