WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 4 of 4] xenpaging: handle paged pages in p2m_pod_

To: Olaf Hering <olaf@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: handle paged pages in p2m_pod_decrease_reservation
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Tue, 4 Oct 2011 17:12:25 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 04 Oct 2011 09:13:15 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LsOw8dGDm2TmohaF4AxoTsZ3BfC3FtMqAGNN/45gU88=; b=mYaadeuKviba09tkh4o/C9EsP/BN6K0RA3TDTkjkQsjoVJsIH9SqEpufbcSQvgL9Cv D5jdVRzHfLCpl4mTUlBc3CIK/ngNPKn7oZ3H6mWWfM55Ne8xDm8XzvBo5iIT05YmUid1 MQh8FVQQSdGqg2aFYkV1Qpd9bGIptsyUszNLY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <b05ede64aaf5f5090fdb.1317653037@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1317653033@xxxxxxxxxxxx> <b05ede64aaf5f5090fdb.1317653037@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, Oct 3, 2011 at 3:43 PM, Olaf Hering <olaf@xxxxxxxxx> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@xxxxxxxxx>
> # Date 1317652812 -7200
> # Node ID b05ede64aaf5f5090fdb844c3a58f1f92d9b3588
> # Parent  13872c432c3807e0f977d9c1311801179807ece2
> xenpaging: handle paged pages in p2m_pod_decrease_reservation
>
> As suggested by <hongkaixing@xxxxxxxxxx>, handle paged pages in PoD code.
>
> Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
>
> diff -r 13872c432c38 -r b05ede64aaf5 xen/arch/x86/mm/p2m-pod.c
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -567,6 +567,21 @@ p2m_pod_decrease_reservation(struct doma
>             BUG_ON(p2m->pod.entry_count < 0);
>             pod--;
>         }
> +        else if ( steal_for_cache && p2m_is_paging(t) )
> +        {
> +            struct page_info *page;
> +            /* alloc a new page to compensate the pod list */

This can't be right.  The whole point of the "populate on demand" was
to pre-allocate a fixed amount of memory, and not need to have to
allocate any more.  What happens if this allocation fails?

It seems like a better thing to do might be this:  If we get a request
to swap out a page, and we still have PoD entries present, we "swap
out" that page as a zero page.

Hmm -- this will take some careful thought...

> +            page = alloc_domheap_page(d, 0);
> +            if ( !page )
> +                goto out_entry_check;
> +            set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid, 
> p2m->default_access);
> +            p2m_mem_paging_drop_page(d, gpfn+i);
> +            p2m_pod_cache_add(p2m, page, 0);
> +            steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
> +            nonpod--;
> +            ram--;
> +        }
> +        /* for other ram types */
>         else if ( steal_for_cache && p2m_is_ram(t) )
>         {
>             struct page_info *page;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel