thr3ads.net - Xen devel - [Xen-devel] [PATCH 3/4] domain heap allocator changes

If this information is useful, please help other people find it:
Share via:

Jan Beulich

2007-Feb-07 17:11 UTC

[Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Hide the (default or user specified) DMA width from anything outside
the heap allocator. I/O-capable guests can now request any width for
the memory they want exchanged/added.

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

Index: 2007-02-07/xen/arch/x86/domain_build.c
==================================================================---
2007-02-07.orig/xen/arch/x86/domain_build.c	2007-02-01 17:41:08.000000000 +0100
+++ 2007-02-07/xen/arch/x86/domain_build.c	2007-02-07 17:12:45.000000000 +0100
@@ -429,11 +429,14 @@ int construct_dom0(struct domain *d,
     if ( (1UL << order) > nr_pages )
         panic("Domain 0 allocation is too small for kernel
image.\n");
 
-    /*
-     * Allocate from DMA pool: on i386 this ensures that our low-memory 1:1
-     * mapping covers the allocation.
-     */
-    if ( (page = alloc_domheap_pages(d, order, MEMF_dma)) == NULL )
+#ifdef __i386__
+    /* Ensure that our low-memory 1:1 mapping covers the allocation. */
+    page = alloc_domheap_pages(d, order,
+                               MEMF_bits(30 + (v_start >> 31)));
+#else
+    page = alloc_domheap_pages(d, order, 0);
+#endif
+    if ( page == NULL )
         panic("Not enough RAM for domain 0 allocation.\n");
     alloc_spfn = page_to_mfn(page);
     alloc_epfn = alloc_spfn + d->tot_pages;
Index: 2007-02-07/xen/common/memory.c
==================================================================---
2007-02-07.orig/xen/common/memory.c	2007-01-30 10:23:30.000000000 +0100
+++ 2007-02-07/xen/common/memory.c	2007-02-07 16:26:50.000000000 +0100
@@ -322,12 +322,12 @@ static long memory_exchange(XEN_GUEST_HA
          (exch.out.address_bits <
           (get_order_from_pages(max_page) + PAGE_SHIFT)) )
     {
-        if ( exch.out.address_bits < dma_bitsize )
+        if ( exch.out.address_bits <= PAGE_SHIFT )
         {
             rc = -ENOMEM;
             goto fail_early;
         }
-        memflags = MEMF_dma;
+        memflags = MEMF_bits(exch.out.address_bits);
     }
 
     if ( exch.in.extent_order <= exch.out.extent_order )
@@ -535,9 +535,9 @@ long do_memory_op(unsigned long cmd, XEN
              (reservation.address_bits <
               (get_order_from_pages(max_page) + PAGE_SHIFT)) )
         {
-            if ( reservation.address_bits < dma_bitsize )
+            if ( reservation.address_bits <= PAGE_SHIFT )
                 return start_extent;
-            args.memflags = MEMF_dma;
+            args.memflags = MEMF_bits(reservation.address_bits);
         }
 
         if ( likely(reservation.domid == DOMID_SELF) )
Index: 2007-02-07/xen/common/page_alloc.c
==================================================================---
2007-02-07.orig/xen/common/page_alloc.c	2007-02-07 16:26:45.000000000 +0100
+++ 2007-02-07/xen/common/page_alloc.c	2007-02-07 17:12:00.000000000 +0100
@@ -48,8 +48,8 @@ string_param("badpage", opt_badpage);
 /*
  * Bit width of the DMA heap.
  */
-unsigned int  dma_bitsize = CONFIG_DMA_BITSIZE;
-unsigned long max_dma_mfn = (1UL << (CONFIG_DMA_BITSIZE - PAGE_SHIFT)) -
1;
+static unsigned int  dma_bitsize = CONFIG_DMA_BITSIZE;
+static unsigned long max_dma_mfn = (1UL << (CONFIG_DMA_BITSIZE -
PAGE_SHIFT)) - 1;
 static void parse_dma_bits(char *s)
 {
     unsigned int v = simple_strtol(s, NULL, 0);
@@ -58,7 +58,7 @@ static void parse_dma_bits(char *s)
         dma_bitsize = BITS_PER_LONG + PAGE_SHIFT;
         max_dma_mfn = ~0UL;
     }
-    else if ( v > PAGE_SHIFT )
+    else if ( v > PAGE_SHIFT + 1 )
     {
         dma_bitsize = v;
         max_dma_mfn = (1UL << (dma_bitsize - PAGE_SHIFT)) - 1;
@@ -711,12 +711,22 @@ struct page_info *__alloc_domheap_pages(
     struct page_info *pg = NULL;
     cpumask_t mask;
     unsigned long i;
+    unsigned int bits = memflags >> _MEMF_bits, zone_hi;
 
     ASSERT(!in_irq());
 
-    if ( !(memflags & MEMF_dma) )
+    if ( bits && bits <= PAGE_SHIFT + 1 )
+        return NULL;
+
+    zone_hi = bits - PAGE_SHIFT - 1;
+    if ( zone_hi >= NR_ZONES )
+        zone_hi = NR_ZONES - 1;
+
+    if ( NR_ZONES + PAGE_SHIFT > dma_bitsize &&
+         (!bits || bits > dma_bitsize) )
     {
-        pg = alloc_heap_pages(dma_bitsize - PAGE_SHIFT, NR_ZONES - 1, cpu,
order);
+        pg = alloc_heap_pages(dma_bitsize - PAGE_SHIFT, zone_hi, cpu, order);
+
         /* Failure? Then check if we can fall back to the DMA pool. */
         if ( unlikely(pg == NULL) &&
              ((order > MAX_ORDER) ||
@@ -729,7 +739,7 @@ struct page_info *__alloc_domheap_pages(
 
     if ( pg == NULL )
         if ( (pg = alloc_heap_pages(MEMZONE_XEN + 1,
-                                    dma_bitsize - PAGE_SHIFT - 1,
+                                    zone_hi,
                                     cpu, order)) == NULL )
             return NULL;
 
Index: 2007-02-07/xen/include/asm-ia64/config.h
==================================================================---
2007-02-07.orig/xen/include/asm-ia64/config.h	2007-01-22 12:26:37.000000000
+0100
+++ 2007-02-07/xen/include/asm-ia64/config.h	2007-02-07 16:26:50.000000000 +0100
@@ -42,7 +42,7 @@
 #define CONFIG_IOSAPIC
 #define supervisor_mode_kernel (0)
 
-#define CONFIG_DMA_BITSIZE 30
+#define CONFIG_DMA_BITSIZE 32
 
 /* If PERFC is used, include privop maps.  */
 #ifdef PERF_COUNTERS
Index: 2007-02-07/xen/include/asm-x86/config.h
==================================================================---
2007-02-07.orig/xen/include/asm-x86/config.h	2007-01-08 14:15:31.000000000 +0100
+++ 2007-02-07/xen/include/asm-x86/config.h	2007-02-07 16:26:50.000000000 +0100
@@ -82,7 +82,7 @@
 /* Debug stack is restricted to 8kB by guard pages. */
 #define DEBUG_STACK_SIZE 8192
 
-#define CONFIG_DMA_BITSIZE 30
+#define CONFIG_DMA_BITSIZE 32
 
 #if defined(__x86_64__)
 
Index: 2007-02-07/xen/include/xen/mm.h
==================================================================---
2007-02-07.orig/xen/include/xen/mm.h	2007-02-07 16:25:40.000000000 +0100
+++ 2007-02-07/xen/include/xen/mm.h	2007-02-07 16:26:50.000000000 +0100
@@ -71,10 +71,10 @@ int assign_pages(
     unsigned int memflags);
 
 /* memflags: */
-#define _MEMF_dma         0
-#define  MEMF_dma         (1U<<_MEMF_dma)
-#define _MEMF_no_refcount 1
+#define _MEMF_no_refcount 0
 #define  MEMF_no_refcount (1U<<_MEMF_no_refcount)
+#define _MEMF_bits        24
+#define  MEMF_bits(n)     ((n)<<_MEMF_bits)
 
 #ifdef CONFIG_PAGEALLOC_MAX_ORDER
 #define MAX_ORDER CONFIG_PAGEALLOC_MAX_ORDER
@@ -82,10 +82,6 @@ int assign_pages(
 #define MAX_ORDER 20 /* 2^20 contiguous pages */
 #endif
 
-/* DMA heap parameters. */
-extern unsigned int  dma_bitsize;
-extern unsigned long max_dma_mfn;
-
 /* Automatic page scrubbing for dead domains. */
 extern struct list_head page_scrub_list;
 #define page_scrub_schedule_work()              \



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

Keir Fraser

2007-Feb-23 18:19 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

On 7/2/07 17:11, "Jan Beulich" <jbeulich@novell.com> wrote:
> Hide the (default or user specified) DMA width from anything outside
> the heap allocator. I/O-capable guests can now request any width for
> the memory they want exchanged/added.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Applied, but this patch turns the ''heap'' list heads in
page_alloc.c into a
barking-mad three-dimensional array which will consume over 1MB of BSS on
x86/64! As it happens it also confuses older versions of the PXELinux mboot
module (at least v0.1) which fails to load the dom0 kernel image correctly.

This array is going to have to become a dynamic-allocated and linked
structure. Perhaps:

struct list_head **heap_by_node[MAX_NUMNODES];
heap_by_node[node] = xmalloc_array(struct list_head **, nr_zones);
heap_by_zone = heap_by_node[node];  /* type: list_head ** */
heap_by_zone[zone] = xmalloc_array(struct list_head, MAX_ORDER+1);
heap_by_order = heap_by_zone[zone]; /* type: list_head * */

I.e., a double indirection to get to a particular heap list_head.

Perhaps I''ll take a look over the weekend...

 -- Keir


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

Chris Lalancette

2007-Feb-23 22:16 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Keir Fraser wrote:> On 7/2/07 17:11, "Jan Beulich" <jbeulich@novell.com> wrote:
> 
> 
>>Hide the (default or user specified) DMA width from anything outside
>>the heap allocator. I/O-capable guests can now request any width for
>>the memory they want exchanged/added.
>>
>>Signed-off-by: Jan Beulich <jbeulich@novell.com>
> 
> 
> Applied, but this patch turns the ''heap'' list heads in
page_alloc.c into a
Keir,
     Has this been applied for inclusion into 3.0.5, or has that branched off
already?  I ask because if it''s not for 3.0.5, I would like to propose
auto-limiting dom0 mem to some reasonable default (say, 32G) for 3.0.5, so that
the HV/dom0 will at least boot on large memory systems.  If it is for 3.0.5,
then this is moot.

Chris Lalancette

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

Keir Fraser

2007-Feb-23 23:09 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

On 23/2/07 22:16, "Chris Lalancette" <clalance@redhat.com>
wrote:
>      Has this been applied for inclusion into 3.0.5, or has that branched
off
> already?  I ask because if it''s not for 3.0.5, I would like to
propose
> auto-limiting dom0 mem to some reasonable default (say, 32G) for 3.0.5, so
> that
> the HV/dom0 will at least boot on large memory systems.  If it is for
3.0.5,
> then this is moot.
It''s going to be included in 3.0.5, but I''m not sure what
difference that
makes as to whether or not we limit dom0_mem?

 -- Keir



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

Keir Fraser

2007-Feb-24 12:22 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

On 23/2/07 18:19, "Keir Fraser" <keir@xensource.com> wrote:
> I.e., a double indirection to get to a particular heap list_head.
> 
> Perhaps I''ll take a look over the weekend...
Done, by the way: should be good enough (reduced overhead for non-numa
system from ~1MB to ~16kB).

I''d like to make the allocation search smarter at some point: avoid
exhaustive search of all viable heaps by instead have empty heaps point at
the next heap to try (with some tradeoff between accuracy of guidance and
cost of maintaining the guidance info; I have some ideas here).

 -- Keir

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

Jan Beulich

2007-Feb-26 08:20 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 24.02.07 13:22
>>>
>On 23/2/07 18:19, "Keir Fraser" <keir@xensource.com> wrote:
>
>> I.e., a double indirection to get to a particular heap list_head.
>> 
>> Perhaps I''ll take a look over the weekend...
>
>Done, by the way: should be good enough (reduced overhead for non-numa
>system from ~1MB to ~16kB).
Thanks!
>I''d like to make the allocation search smarter at some point: avoid
>exhaustive search of all viable heaps by instead have empty heaps point at
>the next heap to try (with some tradeoff between accuracy of guidance and
>cost of maintaining the guidance info; I have some ideas here).
Yes, that was a rough edge I had thought of, too.

Jan

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

Chris Lalancette

2007-Feb-26 13:19 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Keir Fraser wrote:> It''s going to be included in 3.0.5, but I''m not sure what
difference that
> makes as to whether or not we limit dom0_mem?
>
>  -- Keir
>
>   
Keir,
     Excuse me if I misunderstood, but I thought these were the patches
to remove the DMA zone that were alluded to in the other thread about
booting Xen on large memory machines.  If they are those patches, then I
don''t believe we actually need to limit dom0 memory; since the
constrcut_dom0() allocation will come out of the single large zone, it
should Just Work(tm).  If they aren''t those patches, then these have
nothing to do with each other; I apologize for the noise.

Chris Lalancette

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

Keir Fraser

2007-Feb-26 13:25 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

On 26/2/07 13:19, "Chris Lalancette" <clalance@redhat.com>
wrote:
>     Excuse me if I misunderstood, but I thought these were the patches
> to remove the DMA zone that were alluded to in the other thread about
> booting Xen on large memory machines.  If they are those patches, then I
> don''t believe we actually need to limit dom0 memory; since the
> constrcut_dom0() allocation will come out of the single large zone, it
> should Just Work(tm).  If they aren''t those patches, then these
have
> nothing to do with each other; I apologize for the noise.
I think this whole issue is gone away now that Jan''s patches are in the
tree
and will be in the 3.0.5 release.

 -- Keir


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

Chris Lalancette

2007-Feb-26 13:32 UTC

head link

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Keir Fraser wrote:> I think this whole issue is gone away now that Jan''s patches are
in the tree
> and will be in the 3.0.5 release.
>
>  -- Keir
>   Keir,
     Yes, it seems that way.  Thanks for clarifying.

Chris Lalancette

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

Xen devel - Feb 2007 - [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

[Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions

Re: [Xen-devel] [PATCH 3/4] domain heap allocator changes - remove bit width restrictions