xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Dave McCracken <dcm@mccr.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Developers List <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] Implement faster superpage mapping
Date: Fri, 14 May 2010 08:25:41 +0100	[thread overview]
Message-ID: <C812B985.143DE%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <201005131440.22479.dcm@mccr.org>

On 13/05/2010 20:40, "Dave McCracken" <dcm@mccr.org> wrote:

> Here's my first cut of a faster superpage mapping scheme.  It uses a separate
> superpage table to track mappings of superpages and mappings that conflict
> with using a superpage.
> 
> One new feature of this code is that it requires that every superpage be
> allocated to a domain with a single call.  This ensures that every page in the
> superpage is allocated to the same domain.

Hm, not sure about that restriction but in any case it's not the weakest
aspect of the patch by far anyway...

> +static void enable_superpage(
> +    struct page_info *pg,
> +    unsigned int order)
> +{
> +    struct spage_info *spage;
> +    int i;
> +
> +    spage = page_to_spage(pg);
> +    if (order < SUPERPAGE_ORDER)
> +    {
> +        test_and_clear_bit(_SGT_enabled, &spage->type_info);
> +        return;
> +    }        

Why do you need this case? If this superpage is freshly allocated then it
was not previously SGT_enabled, and the flag should be already clear?

> +    if (order == SUPERPAGE_ORDER)
> +    {
> +        test_and_set_bit(_SGT_enabled, &spage->type_info);
> +        return;
> +    }

This case is completely redundant. The for loop would handle it fine.

> +    order -= SUPERPAGE_ORDER;
> +    for(i = 0; i < (1 << order); i++)
> +        test_and_set_bit(_SGT_enabled, &spage[i].type_info);
> +}

And why test_and_*() everywhere? You don't use the result of the test.

> +static void disable_superpage(
> +    struct page_info *pg,
> +    unsigned int order)
> +{
> +    struct spage_info *spage;
> +    int i;
> +
> +    spage = page_to_spage(pg);
> +    test_and_clear_bit(_SGT_enabled, &spage->type_info);

Here we are at the crux of the matter. If a guest frees a page you just
clear the SGT_enabled bit. So the superpage count_info is a completely
pointless creation which is checked absolutely nowhere. The pages can get
reused while stale superpage mappings hang around. Safety off.

> +    if (order > SUPERPAGE_ORDER)
> +    {
> +        order -= SUPERPAGE_ORDER;
> +        for(i = 1; i < (1 << order); i++)
> +        {
> +            BUG_ON((spage[i].type_info & SGT_count_mask) != 0);

Well, here you check the type count. The general count (count_info) would be
more appropriate. Either way, crashing Xen is very obviously unacceptable.

AFAICS, your attempt to be clever on the handling of type conflicts and
avoid ever needing to loop over all the pages in a superpage is so far a
failure. I don't see how you'll successfully avoid it for count_info (page
lifetime) handling, and in that case it may be simpler just to hold both
count_info *and* type_info counts on every page when super_page's associated
counts become non-zero.

I also noted you added another boot parameter. Just pick one name and stick
with it.

 -- Keir

> +            test_and_clear_bit(_SGT_enabled, &spage[i].type_info);
> +        }
> +    }   
> +}



> Dave McCracken
> Oracle Corp.

      reply	other threads:[~2010-05-14  7:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-13 19:40 [PATCH] Implement faster superpage mapping Dave McCracken
2010-05-14  7:25 ` Keir Fraser [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=C812B985.143DE%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=dcm@mccr.org \
    --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 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).