Xen devel - May 2009 - [PATCH] x86: don''t map more than the allocated space for frame_table

This is to avoid undue virtual address aliases in case the over-mapped
pages happen to get allocated to a domain, and then get their
cacheability attributes changed.

At once, use 1Gb mappings if possible and reasonable.

Also, make frame_table a ''mostly read'' variable. Actually, I
don''t
really understand why this has to be a variable on x86 at all -
address calculations involving it could be cheaper if this was just
a #define. Perhaps kexec is the only thing that needs this to be a
variable, but if that indeed is the only reason, kexec should define
its own static variable.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- 2009-05-19.orig/xen/arch/x86/mm.c	2009-03-27 12:40:19.000000000 +0100
+++ 2009-05-19/xen/arch/x86/mm.c	2009-05-20 12:56:01.000000000 +0200
@@ -154,7 +154,7 @@ static DEFINE_PER_CPU(struct percpu_mm_i
 struct domain *dom_xen, *dom_io;
 
 /* Frame table and its size in pages. */
-struct page_info *frame_table;
+struct page_info *__read_mostly frame_table;
 unsigned long max_page;
 unsigned long total_pages;
 
@@ -186,11 +186,18 @@ void __init init_frametable(void)
     frame_table = (struct page_info *)FRAMETABLE_VIRT_START;
 
     nr_pages  = PFN_UP(max_page * sizeof(*frame_table));
-    page_step = (1 << L2_PAGETABLE_SHIFT) >> PAGE_SHIFT;
+    page_step = 1 << (cpu_has_page1gb ? L3_PAGETABLE_SHIFT - PAGE_SHIFT
+                                      : L2_PAGETABLE_SHIFT - PAGE_SHIFT);
 
     for ( i = 0; i < nr_pages; i += page_step )
     {
-        mfn = alloc_boot_pages(min(nr_pages - i, page_step), page_step);
+        /*
+         * The hardcoded 4 below is arbitrary - just pick whatever you think
+         * is reasonable to waste as a trade-off for using a large page.
+         */
+        while (nr_pages + 4 - i < page_step)
+            page_step >>= PAGETABLE_ORDER;
+        mfn = alloc_boot_pages(page_step, page_step);
         if ( mfn == 0 )
             panic("Not enough memory for frame table\n");
         map_pages_to_xen(




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

On 20/05/2009 06:28, "Jan Beulich" <JBeulich@novell.com> wrote:
> Also, make frame_table a ''mostly read'' variable.
Actually, I don''t
> really understand why this has to be a variable on x86 at all -
> address calculations involving it could be cheaper if this was just
> a #define. Perhaps kexec is the only thing that needs this to be a
> variable, but if that indeed is the only reason, kexec should define
> its own static variable.
Would it really be much cheaper? Pointer load versus a 64-bit constant? If
you''re sure it would be an improvement I would take a patch.

 -- Keir



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

>>> Keir Fraser <keir.fraser@eu.citrix.com> 20.05.09 15:56
>>>
>On 20/05/2009 06:28, "Jan Beulich" <JBeulich@novell.com>
wrote:
>
>> Also, make frame_table a ''mostly read'' variable.
Actually, I don''t
>> really understand why this has to be a variable on x86 at all -
>> address calculations involving it could be cheaper if this was just
>> a #define. Perhaps kexec is the only thing that needs this to be a
>> variable, but if that indeed is the only reason, kexec should define
>> its own static variable.
>
>Would it really be much cheaper? Pointer load versus a 64-bit constant? If
>you''re sure it would be an improvement I would take a patch.
Certainly not much (especially with it now sitting in __read_mostly), but the
official latencies are still <= 1 vs >= 2, and additionally memory
clobbers
wouldn''t matter anymore for the compiler''s scheduling
decisions.

Since I wasn''t sure, I didn''t submit a patch right away...

Jan


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