Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-27 Thread David Vrabel
On 11/08/14 18:34, Matt Rushton wrote:
> Instead of ballooning up and down dom0 memory this remaps the existing mfns
> that were replaced by the identity map. The reason for this is that the
> existing implementation ballooned memory up and and down which caused dom0
> to have discontiguous pages. In some cases this resulted in the use of bounce
> buffers which reduced network I/O performance significantly. This change will
> honor the existing order of the pages with the exception of some boundary
> conditions.

Applied to devel/for-linus-3.18.

Patch #1 is already present in 3.17-rc1.

Thanks.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-27 Thread David Vrabel
On 11/08/14 18:34, Matt Rushton wrote:
 Instead of ballooning up and down dom0 memory this remaps the existing mfns
 that were replaced by the identity map. The reason for this is that the
 existing implementation ballooned memory up and and down which caused dom0
 to have discontiguous pages. In some cases this resulted in the use of bounce
 buffers which reduced network I/O performance significantly. This change will
 honor the existing order of the pages with the exception of some boundary
 conditions.

Applied to devel/for-linus-3.18.

Patch #1 is already present in 3.17-rc1.

Thanks.

David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matthew Rushton

On 08/11/14 10:41, Matt Wilson wrote:

On Mon, Aug 11, 2014 at 10:34:01AM -0700, Matt Rushton wrote:

Instead of ballooning up and down dom0 memory this remaps the existing mfns
that were replaced by the identity map. The reason for this is that the
existing implementation ballooned memory up and and down which caused dom0
to have discontiguous pages. In some cases this resulted in the use of bounce
buffers which reduced network I/O performance significantly. This change will
honor the existing order of the pages with the exception of some boundary
conditions.

To do this we need to update both the Linux p2m table and the Xen m2p table.
Particular care must be taken when updating the p2m table since it's important
to limit table memory consumption and reuse the existing leaf pages which get
freed when an entire leaf page is set to the identity map. To implement this,
mapping updates are grouped into blocks with table entries getting cached
temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Signed-off-by: Matthew Rushton 
---

Matt,

Could you provide a summary of v2->v3 changes here?

--msw


  arch/x86/xen/p2m.c   |   23 +---
  arch/x86/xen/p2m.h   |   15 ++
  arch/x86/xen/setup.c |  370 +++---
  3 files changed, 314 insertions(+), 94 deletions(-)
  create mode 100644 arch/x86/xen/p2m.h

Resent patch set with:

v3: One line change to fix 32-bit mfn casting issue with MMU_MACHPHYS_UPDATE

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matt Rushton
Instead of ballooning up and down dom0 memory this remaps the existing mfns
that were replaced by the identity map. The reason for this is that the
existing implementation ballooned memory up and and down which caused dom0
to have discontiguous pages. In some cases this resulted in the use of bounce
buffers which reduced network I/O performance significantly. This change will
honor the existing order of the pages with the exception of some boundary
conditions.

To do this we need to update both the Linux p2m table and the Xen m2p table.
Particular care must be taken when updating the p2m table since it's important
to limit table memory consumption and reuse the existing leaf pages which get
freed when an entire leaf page is set to the identity map. To implement this,
mapping updates are grouped into blocks with table entries getting cached
temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Signed-off-by: Matthew Rushton 
---
v3: One line change to fix 32-bit mfn casting issue with MMU_MACHPHYS_UPDATE 
---
 arch/x86/xen/p2m.c   |   23 +---
 arch/x86/xen/p2m.h   |   15 ++
 arch/x86/xen/setup.c |  370 +++---
 3 files changed, 314 insertions(+), 94 deletions(-)
 create mode 100644 arch/x86/xen/p2m.h

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 3172692..9f5983b 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -173,6 +173,7 @@
 #include 
 #include 
 
+#include "p2m.h"
 #include "multicalls.h"
 #include "xen-ops.h"
 
@@ -180,12 +181,6 @@ static void __init m2p_override_init(void);
 
 unsigned long xen_max_p2m_pfn __read_mostly;
 
-#define P2M_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long))
-#define P2M_MID_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long *))
-#define P2M_TOP_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long **))
-
-#define MAX_P2M_PFN(P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
-
 /* Placeholders for holes in the address space */
 static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
 static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
@@ -202,16 +197,12 @@ static RESERVE_BRK_ARRAY(unsigned long, 
p2m_mid_identity_mfn, P2M_MID_PER_PAGE);
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 RESERVE_BRK(p2m_mid_mfn, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 
-/* We might hit two boundary violations at the start and end, at max each
- * boundary violation will require three middle nodes. */
-RESERVE_BRK(p2m_mid_extra, PAGE_SIZE * 2 * 3);
-
-/* When we populate back during bootup, the amount of pages can vary. The
- * max we have is seen is 395979, but that does not mean it can't be more.
- * Some machines can have 3GB I/O holes even. With early_can_reuse_p2m_middle
- * it can re-use Xen provided mfn_list array, so we only need to allocate at
- * most three P2M top nodes. */
-RESERVE_BRK(p2m_populated, PAGE_SIZE * 3);
+/* For each I/O range remapped we may lose up to two leaf pages for the 
boundary
+ * violations and three mid pages to cover up to 3GB. With
+ * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
+ * remapped region.
+ */
+RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
diff --git a/arch/x86/xen/p2m.h b/arch/x86/xen/p2m.h
new file mode 100644
index 000..ad8aee2
--- /dev/null
+++ b/arch/x86/xen/p2m.h
@@ -0,0 +1,15 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#define P2M_PER_PAGE(PAGE_SIZE / sizeof(unsigned long))
+#define P2M_MID_PER_PAGE(PAGE_SIZE / sizeof(unsigned long *))
+#define P2M_TOP_PER_PAGE(PAGE_SIZE / sizeof(unsigned long **))
+
+#define MAX_P2M_PFN (P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
+
+#define MAX_REMAP_RANGES10
+
+extern unsigned long __init set_phys_range_identity(unsigned long pfn_s,
+  unsigned long pfn_e);
+
+#endif  /* _XEN_P2M_H */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 2e555163..af72161 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -29,6 +29,7 @@
 #include 
 #include "xen-ops.h"
 #include "vdso.h"
+#include "p2m.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -46,6 +47,9 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
+/* Buffer used to remap identity mapped pages */
+unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+
 /* 
  * The maximum amount of extra memory compared to the base size.  The
  * main scaling factor is the size of struct page.  At extreme ratios
@@ -151,107 +155,325 @@ static unsigned long __init 

Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matt Wilson
On Mon, Aug 11, 2014 at 10:34:01AM -0700, Matt Rushton wrote:
> Instead of ballooning up and down dom0 memory this remaps the existing mfns
> that were replaced by the identity map. The reason for this is that the
> existing implementation ballooned memory up and and down which caused dom0
> to have discontiguous pages. In some cases this resulted in the use of bounce
> buffers which reduced network I/O performance significantly. This change will
> honor the existing order of the pages with the exception of some boundary
> conditions.
> 
> To do this we need to update both the Linux p2m table and the Xen m2p table.
> Particular care must be taken when updating the p2m table since it's important
> to limit table memory consumption and reuse the existing leaf pages which get
> freed when an entire leaf page is set to the identity map. To implement this,
> mapping updates are grouped into blocks with table entries getting cached
> temporarily and then released.
> 
> On my test system before:
> Total pages: 2105014
> Total contiguous: 1640635
> 
> After:
> Total pages: 2105014
> Total contiguous: 2098904
> 
> Signed-off-by: Matthew Rushton 
> ---

Matt,

Could you provide a summary of v2->v3 changes here?

--msw

>  arch/x86/xen/p2m.c   |   23 +---
>  arch/x86/xen/p2m.h   |   15 ++
>  arch/x86/xen/setup.c |  370 
> +++---
>  3 files changed, 314 insertions(+), 94 deletions(-)
>  create mode 100644 arch/x86/xen/p2m.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread David Vrabel
On 11/08/14 18:34, Matt Rushton wrote:
> Instead of ballooning up and down dom0 memory this remaps the existing mfns
> that were replaced by the identity map. The reason for this is that the
> existing implementation ballooned memory up and and down which caused dom0
> to have discontiguous pages. In some cases this resulted in the use of bounce
> buffers which reduced network I/O performance significantly. This change will
> honor the existing order of the pages with the exception of some boundary
> conditions.
> 
> To do this we need to update both the Linux p2m table and the Xen m2p table.
> Particular care must be taken when updating the p2m table since it's important
> to limit table memory consumption and reuse the existing leaf pages which get
> freed when an entire leaf page is set to the identity map. To implement this,
> mapping updates are grouped into blocks with table entries getting cached
> temporarily and then released.

What's changed in this version?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matt Rushton
Instead of ballooning up and down dom0 memory this remaps the existing mfns
that were replaced by the identity map. The reason for this is that the
existing implementation ballooned memory up and and down which caused dom0
to have discontiguous pages. In some cases this resulted in the use of bounce
buffers which reduced network I/O performance significantly. This change will
honor the existing order of the pages with the exception of some boundary
conditions.

To do this we need to update both the Linux p2m table and the Xen m2p table.
Particular care must be taken when updating the p2m table since it's important
to limit table memory consumption and reuse the existing leaf pages which get
freed when an entire leaf page is set to the identity map. To implement this,
mapping updates are grouped into blocks with table entries getting cached
temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Signed-off-by: Matthew Rushton 
---
 arch/x86/xen/p2m.c   |   23 +---
 arch/x86/xen/p2m.h   |   15 ++
 arch/x86/xen/setup.c |  370 +++---
 3 files changed, 314 insertions(+), 94 deletions(-)
 create mode 100644 arch/x86/xen/p2m.h

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 3172692..9f5983b 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -173,6 +173,7 @@
 #include 
 #include 
 
+#include "p2m.h"
 #include "multicalls.h"
 #include "xen-ops.h"
 
@@ -180,12 +181,6 @@ static void __init m2p_override_init(void);
 
 unsigned long xen_max_p2m_pfn __read_mostly;
 
-#define P2M_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long))
-#define P2M_MID_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long *))
-#define P2M_TOP_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long **))
-
-#define MAX_P2M_PFN(P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
-
 /* Placeholders for holes in the address space */
 static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
 static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
@@ -202,16 +197,12 @@ static RESERVE_BRK_ARRAY(unsigned long, 
p2m_mid_identity_mfn, P2M_MID_PER_PAGE);
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 RESERVE_BRK(p2m_mid_mfn, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 
-/* We might hit two boundary violations at the start and end, at max each
- * boundary violation will require three middle nodes. */
-RESERVE_BRK(p2m_mid_extra, PAGE_SIZE * 2 * 3);
-
-/* When we populate back during bootup, the amount of pages can vary. The
- * max we have is seen is 395979, but that does not mean it can't be more.
- * Some machines can have 3GB I/O holes even. With early_can_reuse_p2m_middle
- * it can re-use Xen provided mfn_list array, so we only need to allocate at
- * most three P2M top nodes. */
-RESERVE_BRK(p2m_populated, PAGE_SIZE * 3);
+/* For each I/O range remapped we may lose up to two leaf pages for the 
boundary
+ * violations and three mid pages to cover up to 3GB. With
+ * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
+ * remapped region.
+ */
+RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
diff --git a/arch/x86/xen/p2m.h b/arch/x86/xen/p2m.h
new file mode 100644
index 000..ad8aee2
--- /dev/null
+++ b/arch/x86/xen/p2m.h
@@ -0,0 +1,15 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#define P2M_PER_PAGE(PAGE_SIZE / sizeof(unsigned long))
+#define P2M_MID_PER_PAGE(PAGE_SIZE / sizeof(unsigned long *))
+#define P2M_TOP_PER_PAGE(PAGE_SIZE / sizeof(unsigned long **))
+
+#define MAX_P2M_PFN (P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
+
+#define MAX_REMAP_RANGES10
+
+extern unsigned long __init set_phys_range_identity(unsigned long pfn_s,
+  unsigned long pfn_e);
+
+#endif  /* _XEN_P2M_H */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 2e555163..af72161 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -29,6 +29,7 @@
 #include 
 #include "xen-ops.h"
 #include "vdso.h"
+#include "p2m.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -46,6 +47,9 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
+/* Buffer used to remap identity mapped pages */
+unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+
 /* 
  * The maximum amount of extra memory compared to the base size.  The
  * main scaling factor is the size of struct page.  At extreme ratios
@@ -151,107 +155,325 @@ static unsigned long __init xen_do_chunk(unsigned long 
start,
return len;
 }
 
-static unsigned long __init 

[PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matt Rushton
Instead of ballooning up and down dom0 memory this remaps the existing mfns
that were replaced by the identity map. The reason for this is that the
existing implementation ballooned memory up and and down which caused dom0
to have discontiguous pages. In some cases this resulted in the use of bounce
buffers which reduced network I/O performance significantly. This change will
honor the existing order of the pages with the exception of some boundary
conditions.

To do this we need to update both the Linux p2m table and the Xen m2p table.
Particular care must be taken when updating the p2m table since it's important
to limit table memory consumption and reuse the existing leaf pages which get
freed when an entire leaf page is set to the identity map. To implement this,
mapping updates are grouped into blocks with table entries getting cached
temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Signed-off-by: Matthew Rushton mrush...@amazon.com
---
 arch/x86/xen/p2m.c   |   23 +---
 arch/x86/xen/p2m.h   |   15 ++
 arch/x86/xen/setup.c |  370 +++---
 3 files changed, 314 insertions(+), 94 deletions(-)
 create mode 100644 arch/x86/xen/p2m.h

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 3172692..9f5983b 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -173,6 +173,7 @@
 #include xen/balloon.h
 #include xen/grant_table.h
 
+#include p2m.h
 #include multicalls.h
 #include xen-ops.h
 
@@ -180,12 +181,6 @@ static void __init m2p_override_init(void);
 
 unsigned long xen_max_p2m_pfn __read_mostly;
 
-#define P2M_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long))
-#define P2M_MID_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long *))
-#define P2M_TOP_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long **))
-
-#define MAX_P2M_PFN(P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
-
 /* Placeholders for holes in the address space */
 static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
 static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
@@ -202,16 +197,12 @@ static RESERVE_BRK_ARRAY(unsigned long, 
p2m_mid_identity_mfn, P2M_MID_PER_PAGE);
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 RESERVE_BRK(p2m_mid_mfn, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 
-/* We might hit two boundary violations at the start and end, at max each
- * boundary violation will require three middle nodes. */
-RESERVE_BRK(p2m_mid_extra, PAGE_SIZE * 2 * 3);
-
-/* When we populate back during bootup, the amount of pages can vary. The
- * max we have is seen is 395979, but that does not mean it can't be more.
- * Some machines can have 3GB I/O holes even. With early_can_reuse_p2m_middle
- * it can re-use Xen provided mfn_list array, so we only need to allocate at
- * most three P2M top nodes. */
-RESERVE_BRK(p2m_populated, PAGE_SIZE * 3);
+/* For each I/O range remapped we may lose up to two leaf pages for the 
boundary
+ * violations and three mid pages to cover up to 3GB. With
+ * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
+ * remapped region.
+ */
+RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
diff --git a/arch/x86/xen/p2m.h b/arch/x86/xen/p2m.h
new file mode 100644
index 000..ad8aee2
--- /dev/null
+++ b/arch/x86/xen/p2m.h
@@ -0,0 +1,15 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#define P2M_PER_PAGE(PAGE_SIZE / sizeof(unsigned long))
+#define P2M_MID_PER_PAGE(PAGE_SIZE / sizeof(unsigned long *))
+#define P2M_TOP_PER_PAGE(PAGE_SIZE / sizeof(unsigned long **))
+
+#define MAX_P2M_PFN (P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
+
+#define MAX_REMAP_RANGES10
+
+extern unsigned long __init set_phys_range_identity(unsigned long pfn_s,
+  unsigned long pfn_e);
+
+#endif  /* _XEN_P2M_H */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 2e555163..af72161 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -29,6 +29,7 @@
 #include xen/features.h
 #include xen-ops.h
 #include vdso.h
+#include p2m.h
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -46,6 +47,9 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
+/* Buffer used to remap identity mapped pages */
+unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+
 /* 
  * The maximum amount of extra memory compared to the base size.  The
  * main scaling factor is the size of struct page.  At extreme ratios
@@ -151,107 +155,325 @@ static unsigned long __init xen_do_chunk(unsigned long 
start,

Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread David Vrabel
On 11/08/14 18:34, Matt Rushton wrote:
 Instead of ballooning up and down dom0 memory this remaps the existing mfns
 that were replaced by the identity map. The reason for this is that the
 existing implementation ballooned memory up and and down which caused dom0
 to have discontiguous pages. In some cases this resulted in the use of bounce
 buffers which reduced network I/O performance significantly. This change will
 honor the existing order of the pages with the exception of some boundary
 conditions.
 
 To do this we need to update both the Linux p2m table and the Xen m2p table.
 Particular care must be taken when updating the p2m table since it's important
 to limit table memory consumption and reuse the existing leaf pages which get
 freed when an entire leaf page is set to the identity map. To implement this,
 mapping updates are grouped into blocks with table entries getting cached
 temporarily and then released.

What's changed in this version?

David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matt Wilson
On Mon, Aug 11, 2014 at 10:34:01AM -0700, Matt Rushton wrote:
 Instead of ballooning up and down dom0 memory this remaps the existing mfns
 that were replaced by the identity map. The reason for this is that the
 existing implementation ballooned memory up and and down which caused dom0
 to have discontiguous pages. In some cases this resulted in the use of bounce
 buffers which reduced network I/O performance significantly. This change will
 honor the existing order of the pages with the exception of some boundary
 conditions.
 
 To do this we need to update both the Linux p2m table and the Xen m2p table.
 Particular care must be taken when updating the p2m table since it's important
 to limit table memory consumption and reuse the existing leaf pages which get
 freed when an entire leaf page is set to the identity map. To implement this,
 mapping updates are grouped into blocks with table entries getting cached
 temporarily and then released.
 
 On my test system before:
 Total pages: 2105014
 Total contiguous: 1640635
 
 After:
 Total pages: 2105014
 Total contiguous: 2098904
 
 Signed-off-by: Matthew Rushton mrush...@amazon.com
 ---

Matt,

Could you provide a summary of v2-v3 changes here?

--msw

  arch/x86/xen/p2m.c   |   23 +---
  arch/x86/xen/p2m.h   |   15 ++
  arch/x86/xen/setup.c |  370 
 +++---
  3 files changed, 314 insertions(+), 94 deletions(-)
  create mode 100644 arch/x86/xen/p2m.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matt Rushton
Instead of ballooning up and down dom0 memory this remaps the existing mfns
that were replaced by the identity map. The reason for this is that the
existing implementation ballooned memory up and and down which caused dom0
to have discontiguous pages. In some cases this resulted in the use of bounce
buffers which reduced network I/O performance significantly. This change will
honor the existing order of the pages with the exception of some boundary
conditions.

To do this we need to update both the Linux p2m table and the Xen m2p table.
Particular care must be taken when updating the p2m table since it's important
to limit table memory consumption and reuse the existing leaf pages which get
freed when an entire leaf page is set to the identity map. To implement this,
mapping updates are grouped into blocks with table entries getting cached
temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Signed-off-by: Matthew Rushton mrush...@amazon.com
---
v3: One line change to fix 32-bit mfn casting issue with MMU_MACHPHYS_UPDATE 
---
 arch/x86/xen/p2m.c   |   23 +---
 arch/x86/xen/p2m.h   |   15 ++
 arch/x86/xen/setup.c |  370 +++---
 3 files changed, 314 insertions(+), 94 deletions(-)
 create mode 100644 arch/x86/xen/p2m.h

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 3172692..9f5983b 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -173,6 +173,7 @@
 #include xen/balloon.h
 #include xen/grant_table.h
 
+#include p2m.h
 #include multicalls.h
 #include xen-ops.h
 
@@ -180,12 +181,6 @@ static void __init m2p_override_init(void);
 
 unsigned long xen_max_p2m_pfn __read_mostly;
 
-#define P2M_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long))
-#define P2M_MID_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long *))
-#define P2M_TOP_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long **))
-
-#define MAX_P2M_PFN(P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
-
 /* Placeholders for holes in the address space */
 static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
 static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
@@ -202,16 +197,12 @@ static RESERVE_BRK_ARRAY(unsigned long, 
p2m_mid_identity_mfn, P2M_MID_PER_PAGE);
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 RESERVE_BRK(p2m_mid_mfn, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 
-/* We might hit two boundary violations at the start and end, at max each
- * boundary violation will require three middle nodes. */
-RESERVE_BRK(p2m_mid_extra, PAGE_SIZE * 2 * 3);
-
-/* When we populate back during bootup, the amount of pages can vary. The
- * max we have is seen is 395979, but that does not mean it can't be more.
- * Some machines can have 3GB I/O holes even. With early_can_reuse_p2m_middle
- * it can re-use Xen provided mfn_list array, so we only need to allocate at
- * most three P2M top nodes. */
-RESERVE_BRK(p2m_populated, PAGE_SIZE * 3);
+/* For each I/O range remapped we may lose up to two leaf pages for the 
boundary
+ * violations and three mid pages to cover up to 3GB. With
+ * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
+ * remapped region.
+ */
+RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
diff --git a/arch/x86/xen/p2m.h b/arch/x86/xen/p2m.h
new file mode 100644
index 000..ad8aee2
--- /dev/null
+++ b/arch/x86/xen/p2m.h
@@ -0,0 +1,15 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#define P2M_PER_PAGE(PAGE_SIZE / sizeof(unsigned long))
+#define P2M_MID_PER_PAGE(PAGE_SIZE / sizeof(unsigned long *))
+#define P2M_TOP_PER_PAGE(PAGE_SIZE / sizeof(unsigned long **))
+
+#define MAX_P2M_PFN (P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
+
+#define MAX_REMAP_RANGES10
+
+extern unsigned long __init set_phys_range_identity(unsigned long pfn_s,
+  unsigned long pfn_e);
+
+#endif  /* _XEN_P2M_H */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 2e555163..af72161 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -29,6 +29,7 @@
 #include xen/features.h
 #include xen-ops.h
 #include vdso.h
+#include p2m.h
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -46,6 +47,9 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
+/* Buffer used to remap identity mapped pages */
+unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+
 /* 
  * The maximum amount of extra memory compared to the base size.  The
  * main scaling factor is the size of struct page.  At extreme ratios
@@ 

Re: [PATCH v3 2/2] xen/setup: Remap Xen Identity Mapped RAM

2014-08-11 Thread Matthew Rushton

On 08/11/14 10:41, Matt Wilson wrote:

On Mon, Aug 11, 2014 at 10:34:01AM -0700, Matt Rushton wrote:

Instead of ballooning up and down dom0 memory this remaps the existing mfns
that were replaced by the identity map. The reason for this is that the
existing implementation ballooned memory up and and down which caused dom0
to have discontiguous pages. In some cases this resulted in the use of bounce
buffers which reduced network I/O performance significantly. This change will
honor the existing order of the pages with the exception of some boundary
conditions.

To do this we need to update both the Linux p2m table and the Xen m2p table.
Particular care must be taken when updating the p2m table since it's important
to limit table memory consumption and reuse the existing leaf pages which get
freed when an entire leaf page is set to the identity map. To implement this,
mapping updates are grouped into blocks with table entries getting cached
temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Signed-off-by: Matthew Rushton mrush...@amazon.com
---

Matt,

Could you provide a summary of v2-v3 changes here?

--msw


  arch/x86/xen/p2m.c   |   23 +---
  arch/x86/xen/p2m.h   |   15 ++
  arch/x86/xen/setup.c |  370 +++---
  3 files changed, 314 insertions(+), 94 deletions(-)
  create mode 100644 arch/x86/xen/p2m.h

Resent patch set with:

v3: One line change to fix 32-bit mfn casting issue with MMU_MACHPHYS_UPDATE

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/