From: Julien Grall <julien.grall@citrix.com>
To: "Chris (Christopher) Brand" <chris.brand@broadcom.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
"Ian Campbell (ian.campbell@citrix.com)"
<ian.campbell@citrix.com>
Subject: Re: [PATCH] xen: arm: Support <32MB frametables
Date: Fri, 7 Aug 2015 15:28:49 +0100 [thread overview]
Message-ID: <55C4C0A1.6010804@citrix.com> (raw)
In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7E5B47@SJEXCHMB05.corp.ad.broadcom.com>
Hi Chris,
On 06/08/15 18:54, Chris (Christopher) Brand wrote:
> setup_frametable_mappings() rounds frametable_size up to a multiple
> of 32MB. This is wasteful on systems with less than 4GB of RAM,
> although it does allow the "contig" bit to be set in the PTEs.
>
> Where the frametable is less than 32MB in size, instead round up
> to a multiple of 2MB, not setting the "contig" bit in the PTEs.
OOI, you win 30MB of RAM but how does this affect the performance?
> Signed-off-by: Chris Brand <chris.brand@broadcom.com>
> ---
> xen/arch/arm/mm.c | 39 ++++++++++++++++++++++++++++++++++++---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index a91ea774f1f9..47b6d5d44563 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> #ifdef CONFIG_ARM_32
> +static void __init create_2mb_mappings(lpae_t *second,
> + unsigned long virt_offset,
> + unsigned long base_mfn,
> + unsigned long nr_mfns)
> +{
> + unsigned long i, count;
> + lpae_t pte, *p;
> +
> + ASSERT(!((virt_offset >> PAGE_SHIFT) % LPAE_ENTRIES));
> + ASSERT(!(base_mfn % LPAE_ENTRIES));
> + ASSERT(!(nr_mfns % LPAE_ENTRIES));
> +
> + count = nr_mfns / LPAE_ENTRIES;
> + p = second + second_linear_offset(virt_offset);
> + pte = mfn_to_xen_entry(base_mfn, WRITEALLOC);
> + for ( i = 0; i < count; i++ )
> + {
> + write_pte(p + i, pte);
> + pte.pt.base += 1 << LPAE_SHIFT;
> + }
> + flush_xen_data_tlb_local();
> +}
> +
Can you rework create_32mb_mappings to take the size of the mappings in
parameters?
> /* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
> void __init setup_xenheap_mappings(unsigned long base_mfn,
> unsigned long nr_mfns)
> @@ -749,6 +772,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
> unsigned long nr_pdxs = pfn_to_pdx(nr_pages);
> unsigned long frametable_size = nr_pdxs * sizeof(struct page_info);
> unsigned long base_mfn;
> + unsigned long mask;
> #ifdef CONFIG_ARM_64
> lpae_t *second, pte;
> unsigned long nr_second, second_base;
> @@ -757,8 +781,12 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
>
> frametable_base_pdx = pfn_to_pdx(ps >> PAGE_SHIFT);
>
> - /* Round up to 32M boundary */
> - frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
> + /* Round up to 2M or 32M boundary, as appropriate. */
> + if ( frametable_size < MB(32) )
> + mask = MB(2) - 1;
> + else
> + mask = MB(32) - 1;
> + frametable_size = (frametable_size + mask) & ~mask;
You can use ROUNDUP(frametable_size, size) to avoid open-coding the mask.
Also, this code is common with ARM64. If we happen to have a board with
a frametable smaller than 32MB, you will round up to 2MB and crash later
in create_32mb_mappings because you don't support 2MB mapping for ARM64.
It might be good to support 2MB for ARM64 too.
> base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));
>
> #ifdef CONFIG_ARM_64
> @@ -773,7 +801,12 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
> }
> create_32mb_mappings(second, 0, base_mfn, frametable_size >> PAGE_SHIFT);
> #else
> - create_32mb_mappings(xen_second, FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
> + if ( frametable_size < MB(32) )
> + create_2mb_mappings(xen_second, FRAMETABLE_VIRT_START,
> + base_mfn, frametable_size >> PAGE_SHIFT);
> + else
> + create_32mb_mappings(xen_second, FRAMETABLE_VIRT_START,
> + base_mfn, frametable_size >> PAGE_SHIFT);
Passing the size/alignment in parameter would have avoid to add this
if/else. You can use the new parameter to ASSERT the input and enable or
not the contiguous bit.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-08-07 14:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-06 17:54 [PATCH] xen: arm: Support <32MB frametables Chris (Christopher) Brand
2015-08-07 14:28 ` Julien Grall [this message]
2015-08-07 17:29 ` Chris (Christopher) Brand
2015-08-14 10:01 ` Julien Grall
2015-08-07 17:36 ` Chris (Christopher) Brand
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=55C4C0A1.6010804@citrix.com \
--to=julien.grall@citrix.com \
--cc=chris.brand@broadcom.com \
--cc=ian.campbell@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=xen-devel@lists.xen.org \
/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.