diff mbox series

[v5,20/31] powerpc/fadump: use smaller offset while finding memory for reservation

Message ID 156630279483.8896.5669371616456324826.stgit@hbathini.in.ibm.com (mailing list archive)
State Superseded
Headers show
Series Add FADump support on PowerNV platform | expand

Checks

Context Check Description
snowpatch_ozlabs/apply_patch success Successfully applied on branch next (c9633332103e55bc73d80d07ead28b95a22a85a3)
snowpatch_ozlabs/checkpatch success total: 0 errors, 0 warnings, 0 checks, 22 lines checked

Commit Message

Hari Bathini Aug. 20, 2019, 12:06 p.m. UTC
Use a smaller offset, instead of size of the memory to be reserved by
which to skip memory before making another attempt at reserving memory,
after the previous attempt to reserve memory for FADump failed due to
memory holes and/or reserved ranges, to reduce the likelihood of memory
reservation failure.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
 arch/powerpc/kernel/fadump-common.h |    8 ++++++++
 arch/powerpc/kernel/fadump.c        |    2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

Comments

Michael Ellerman Sept. 4, 2019, 11:54 a.m. UTC | #1
Hari Bathini <hbathini@linux.ibm.com> writes:
> diff --git a/arch/powerpc/kernel/fadump-common.h b/arch/powerpc/kernel/fadump-common.h
> index d2dd117..7107cf2 100644
> --- a/arch/powerpc/kernel/fadump-common.h
> +++ b/arch/powerpc/kernel/fadump-common.h
> @@ -66,6 +66,14 @@ static inline u64 fadump_str_to_u64(const char *str)
>  
>  #define FADUMP_CRASH_INFO_MAGIC		fadump_str_to_u64("FADMPINF")
>  
> +/*
> + * Amount of memory (1024MB) to skip before making another attempt at
> + * reserving memory (after the previous attempt to reserve memory for
> + * FADump failed due to memory holes and/or reserved ranges) to reduce
> + * the likelihood of memory reservation failure.
> + */
> +#define FADUMP_OFFSET_SIZE			0x40000000U

This seems like a bit of a hack.

> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 971c50d..8dd2dcc 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -371,7 +371,7 @@ int __init fadump_reserve_mem(void)
>  			    !memblock_is_region_reserved(base, size))
>  				break;
>  
> -			base += size;
> +			base += FADUMP_OFFSET_SIZE;
>  		}

The comment above the loop says:

		/*
		 * Reserve memory at an offset closer to bottom of the RAM to
		 * minimize the impact of memory hot-remove operation. We can't
		 * use memblock_find_in_range() here since it doesn't allocate
		 * from bottom to top.
		 */

Is that true? Can't we set memblock to bottom up mode and then call it?

cheers
diff mbox series

Patch

diff --git a/arch/powerpc/kernel/fadump-common.h b/arch/powerpc/kernel/fadump-common.h
index d2dd117..7107cf2 100644
--- a/arch/powerpc/kernel/fadump-common.h
+++ b/arch/powerpc/kernel/fadump-common.h
@@ -66,6 +66,14 @@  static inline u64 fadump_str_to_u64(const char *str)
 
 #define FADUMP_CRASH_INFO_MAGIC		fadump_str_to_u64("FADMPINF")
 
+/*
+ * Amount of memory (1024MB) to skip before making another attempt at
+ * reserving memory (after the previous attempt to reserve memory for
+ * FADump failed due to memory holes and/or reserved ranges) to reduce
+ * the likelihood of memory reservation failure.
+ */
+#define FADUMP_OFFSET_SIZE			0x40000000U
+
 /* fadump crash info structure */
 struct fadump_crash_info_header {
 	u64		magic_number;
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 971c50d..8dd2dcc 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -371,7 +371,7 @@  int __init fadump_reserve_mem(void)
 			    !memblock_is_region_reserved(base, size))
 				break;
 
-			base += size;
+			base += FADUMP_OFFSET_SIZE;
 		}
 
 		if (base > (memory_boundary - size)) {