From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] xen: correctly rebuild mfn list list after migration.
Date: Thu, 14 Oct 2010 07:55:34 +0100 [thread overview]
Message-ID: <1287039334.5663.186.camel@localhost.localdomain> (raw)
In-Reply-To: <4CB6603F.6070703@goop.org>
On Thu, 2010-10-14 at 02:43 +0100, Jeremy Fitzhardinge wrote:
> On 10/12/2010 03:14 AM, Ian Campbell wrote:
> > static RESERVE_BRK_ARRAY(unsigned long **, p2m_top, P2M_TOP_PER_PAGE);
> > static RESERVE_BRK_ARRAY(unsigned long, p2m_top_mfn, P2M_TOP_PER_PAGE);
> > +static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_mfn_p, P2M_TOP_PER_PAGE);
>
> This should be called "p2m_top_mfn_p" to have consistent naming, since
> its at the top of the hierarchy and is indexed by topidx. The "mid" in
> the name makes it look like it should be indexed by mididx, but then it
> wouldn't make sense to have just one of these (since there needs to be a
> mid for each entry in top). The fact that it points to mids is
> irrelevant (or at least implied by the fact that its a top).
OK.
> > @@ -322,14 +339,19 @@ void xen_build_mfn_list_list(void)
> > mid = p2m_top[topidx];
> >
> > /* Don't bother allocating any mfn mid levels if
> > - they're just missing */
> > - if (mid[mididx] == p2m_missing)
> > + * they're just missing, just update the stored mfn,
> > + * since all could have changed over a migrate.
> > + */
> > + if (mid == p2m_mid_missing) {
> > + p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing);
> > + pfn += P2M_MID_PER_PAGE - 1;
>
> Why -1? How does this interact with the "pfn += P2M_PER_PAGE" in the
> for loop? Should it be "(P2M_MID_PER_PAGE - 1) * P2M_PER_PAGE", with
> the pfn += P2M_PER_PAGE moved to the bottom of the loop rather than in
> the header?
The -1 was supposed to offset the ++ in the for header, except as you
point out its actually a +=.
I'll figure out what the correct increment should be.
> Is this test even necessary? Is it to save redundant re-testing of the
> mid level?
It avoids descending P2M_MID_PER_PAGE times per p2m_mis_missing top
level entry into leaf entries which we know are going to be p2m_missing
because they are referred to by p2m_mid_missing. Perhaps its a premature
optimisation, if the test and increment end up too complex once I've
fixed them I may just drop it.
Ian.
prev parent reply other threads:[~2010-10-14 6:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 10:14 [PATCH] xen: correctly rebuild mfn list list after migration Ian Campbell
2010-10-14 0:37 ` Jeremy Fitzhardinge
2010-10-14 6:49 ` Ian Campbell
2010-10-14 8:51 ` Ian Campbell
2010-10-14 18:27 ` Jeremy Fitzhardinge
2010-10-21 10:10 ` Ian Campbell
2010-10-21 17:10 ` Jeremy Fitzhardinge
2010-10-21 17:28 ` Ian Campbell
2010-10-14 1:43 ` Jeremy Fitzhardinge
2010-10-14 6:55 ` Ian Campbell [this message]
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=1287039334.5663.186.camel@localhost.localdomain \
--to=ian.campbell@eu.citrix.com \
--cc=jeremy@goop.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.