From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC PATCH] page_alloc: use first half of higher
 order chunks when halving
Date: Tue, 25 Mar 2014 11:44:19 +0000
Message-ID: <53316C13.4090006@citrix.com>
References: <1395746524-9670-1-git-send-email-msw@linux.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1WSPmK-0007M0-RS
	for xen-devel@lists.xenproject.org; Tue, 25 Mar 2014 11:44:25 +0000
In-Reply-To: <1395746524-9670-1-git-send-email-msw@linux.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Matt Wilson <msw@linux.com>
Cc: Keir Fraser <keir@xen.org>, Matt Wilson <msw@amazon.com>, Tim Deegan <tim@xen.org>, Matt Rushton <mrushton@amazon.com>, Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

On 25/03/14 11:22, Matt Wilson wrote:
> From: Matt Rushton <mrushton@amazon.com>
>
> This patch makes the Xen heap allocator use the first half of higher
> order chunks instead of the second half when breaking them down for
> smaller order allocations.
>
> Linux currently remaps the memory overlapping PCI space one page at a
> time. Before this change this resulted in the mfns being allocated in
> reverse order and led to discontiguous dom0 memory. This forced dom0
> to use bounce buffers for doing DMA and resulted in poor performance.
>
> This change more gracefully handles the dom0 use case and returns
> contiguous memory for subsequent allocations.
>
> Cc: xen-devel@lists.xenproject.org
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Matt Rushton <mrushton@amazon.com>
> Signed-off-by: Matt Wilson <msw@amazon.com>

How does dom0 work out that it is safe to join multiple pfns into a dma
buffer without the swiotlb?

> ---
>  xen/common/page_alloc.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 601319c..27e7f18 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -677,9 +677,10 @@ static struct page_info *alloc_heap_pages(
>      /* We may have to halve the chunk a number of times. */
>      while ( j != order )
>      {
> -        PFN_ORDER(pg) = --j;
> +        struct page_info *pg2;

At the very least, Xen style mandates a blank line after this variable
declaration.

~Andrew

> +        pg2 = pg + (1 << --j);
> +        PFN_ORDER(pg) = j;
>          page_list_add_tail(pg, &heap(node, zone, j));
> -        pg += 1 << j;
>      }
>  
>      ASSERT(avail[node][zone] >= request);