[kexec-tools] Stop maximizing the bitmap buffer to reduce the risk of OOM.

WANG Chao wangchao at fedoraproject.org
Wed Jul 16 06:57:31 UTC 2014


commit e5769870b1b55beaa21ada44ff1cb4f56354c4c9
Author: Baoquan He <bhe at redhat.com>
Date:   Tue Jul 15 15:50:25 2014 +0800

    Stop maximizing the bitmap buffer to reduce the risk of OOM.
    
    This is a backport of the following upstream commit.
    
    commit 0b732828091a545185ad13d0b2e6800600788d61
    Author: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
    Date:   Tue Jun 10 13:57:29 2014 +0900
    
        [PATCH 3/3] Stop maximizing the bitmap buffer to reduce the risk of OOM.
    
        We tried to maximize the bitmap buffer to get the best performance,
        but the performance degradation caused by multi-cycle processing
        looks very small according to the benchmark on 2TB memory:
    
          https://lkml.org/lkml/2013/3/26/914
    
        This result means we don't need to make an effort to maximize the
        bitmap buffer, it will just increase the risk of OOM.
    
        This patch sets a small fixed value (4MB) as a safety limit,
        it may be safer and enough in most cases.
    
        Signed-off-by: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
    
    Signed-off-by: Baoquan He <bhe at redhat.com>
    Acked-by: Vivek Goyal <vgoyal at redhat.com>

 ...top-maximizing-the-bitmap-buffer-to-reduc.patch |   73 ++++++++++++++++++++
 kexec-tools.spec                                   |    2 +
 2 files changed, 75 insertions(+), 0 deletions(-)
---
diff --git a/kexec-tools-2.0.4-makedumpfile-Stop-maximizing-the-bitmap-buffer-to-reduc.patch b/kexec-tools-2.0.4-makedumpfile-Stop-maximizing-the-bitmap-buffer-to-reduc.patch
new file mode 100644
index 0000000..db8ee92
--- /dev/null
+++ b/kexec-tools-2.0.4-makedumpfile-Stop-maximizing-the-bitmap-buffer-to-reduc.patch
@@ -0,0 +1,73 @@
+From 0b732828091a545185ad13d0b2e6800600788d61 Mon Sep 17 00:00:00 2001
+From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
+Date: Tue, 10 Jun 2014 13:57:29 +0900
+Subject: [PATCH] [PATCH 3/3] Stop maximizing the bitmap buffer to reduce the
+ risk of OOM.
+
+We tried to maximize the bitmap buffer to get the best performance,
+but the performance degradation caused by multi-cycle processing
+looks very small according to the benchmark on 2TB memory:
+
+  https://lkml.org/lkml/2013/3/26/914
+
+This result means we don't need to make an effort to maximize the
+bitmap buffer, it will just increase the risk of OOM.
+
+This patch sets a small fixed value (4MB) as a safety limit,
+it may be safer and enough in most cases.
+
+Signed-off-by: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
+Signed-off-by: Baoquan He <bhe at redhat.com>
+---
+ makedumpfile.c | 17 ++++++++++-------
+ 1 file changed, 10 insertions(+), 7 deletions(-)
+
+diff --git a/makedumpfile.c b/makedumpfile.c
+index b8f1ec4..3884aa5 100644
+--- a/makedumpfile-1.5.6/makedumpfile.c
++++ b/makedumpfile-1.5.6/makedumpfile.c
+@@ -8946,13 +8946,15 @@ out:
+ 
+ 
+ /*
+- * Choose the lesser value of the two below as the size of cyclic buffer.
+- *  - the size enough for storing the 1st/2nd bitmap for the whole of vmcore
+- *  - 80% of free memory (as safety limit)
++ * Choose the less value of the three below as the size of cyclic buffer.
++ *  - the size enough for storing the 1st or 2nd bitmap for the whole of vmcore
++ *  - 4MB as sufficient value
++ *  - 60% of free memory as safety limit
+  */
+ int
+ calculate_cyclic_buffer_size(void) {
+ 	unsigned long long limit_size, bitmap_size;
++	const unsigned long long maximum_size = 4 * 1024 * 1024;
+ 
+ 	if (info->max_mapnr <= 0) {
+ 		ERRMSG("Invalid max_mapnr(%llu).\n", info->max_mapnr);
+@@ -8960,17 +8962,18 @@ calculate_cyclic_buffer_size(void) {
+ 	}
+ 
+ 	/*
+-	 *  We should keep the size of cyclic buffer within 80% of free memory
+-	 *  for safety.
++	 *  At least, we should keep the size of cyclic buffer within 60% of
++	 *  free memory for safety.
+ 	 */
+-	limit_size = get_free_memory_size() * 0.8;
++	limit_size = get_free_memory_size() * 0.6;
+ 	bitmap_size = info->max_mapnr / BITPERBYTE;
+ 
+ 	/* if --split was specified cyclic buffer allocated per dump file */
+ 	if (info->num_dumpfile > 1)
+ 		bitmap_size /= info->num_dumpfile;
+ 
+-	info->bufsize_cyclic = MIN(limit_size, bitmap_size);
++	/* 4MB will be enough for performance according to benchmarks. */
++	info->bufsize_cyclic = MIN(MIN(limit_size, maximum_size), bitmap_size);
+ 
+ 	return TRUE;
+ }
+-- 
+1.8.5.3
+
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 114df4c..218a93c 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -80,6 +80,7 @@ Patch603: kexec-tools-2.0.4-makedumpfile-Introduce-the-mdf_pfn_t-type.patch
 Patch604: kexec-tools-2.0.4-makedumpfile-Fix-free-bitmap_buffer_cyclic-error.patch
 Patch605: kexec-tools-2.0.4-makedumpfile-Remove-the-1st-bitmap-buffer-from-the-ELF-.patch
 Patch606: kexec-tools-2.0.4-makedumpfile-Move-counting-pfn_memhole-for-cyclic-mode.patch
+Patch607: kexec-tools-2.0.4-makedumpfile-Stop-maximizing-the-bitmap-buffer-to-reduc.patch
 
 %description
 kexec-tools provides /sbin/kexec binary that facilitates a new
@@ -121,6 +122,7 @@ tar -z -x -v -f %{SOURCE23}
 %patch604 -p1
 %patch605 -p1
 %patch606 -p1
+%patch607 -p1
 
 tar -z -x -v -f %{SOURCE13}
 


More information about the scm-commits mailing list