[PATCH V2 3/4] munmap: kbuild menu for munmap interface

[Geunsik Lim]

From: Geunsik Lim <geunsik.lim@xxxxxxxxxxx>

Support kbuild menu to select memory unmap operation size
at build time.

Signed-off-by: Geunsik Lim <geunsik.lim@xxxxxxxxxxx>
Acked-by: Hyunjin Choi <hj89.choi@xxxxxxxxxxx>
CC: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
CC: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
CC: Steven Rostedt <rostedt@xxxxxxxxxx>
CC: Hugh Dickins <hughd@xxxxxxxxxx>
CC: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
CC: Ingo Molnar <mingo@xxxxxxx>
---
 init/Kconfig |   70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 84 insertions(+), 7 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 56240e7..47283ed 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -557,6 +557,79 @@ config LOG_BUF_SHIFT
 		     13 =>  8 KB
 		     12 =>  4 KB
 
+config PREEMPT_OK_MUNMAP_RANGE
+	int "Memory unmap unit on preemptive mode (8 => 32KB)"
+	depends on !PREEMPT_NONE
+	range 8 2048
+	default 8
+	help
+	  unmap_vmas(= unmap a range of memory covered by a list of vma) is
+	  treading a delicate and uncomfortable line between high performance
+	  and low latency.
+	  This option improves performance at the expense of latency.
+
+	  So although there may be no need to reschedule right now,
+	  if we keep on gathering more and more memory without flushing,
+	  we'll be very unresponsive when a reschedule is needed later on.
+
+	  Consider the best suitable result between high performance and
+	  low latency on preempt mode. Select optimal munmap size to return
+          memory space that is allocated by mmap system call.
+
+	  For example, for recording mass files, if we try to unmap memory
+	  that we allocated with 100MB for recording in embedded devices,
+	  we have to wait for more than 3 seconds to change mode from play
+	  mode to recording mode. This results from the unit of memory unmapped
+	  size when we are recording mass files like camcorder particularly.
+
+	  This value can be changed after boot using the
+	  /proc/sys/vm/munmap_unit_size tunable.
+
+	  Examples:
+                  2048 => 8,388,608 bytes : for straight-line efficiency
+                  1024 => 4,194,304 bytes
+                   512 => 2,097,152 bytes
+                   256 => 1,048,576 bytes
+                   128 =>   524,288 bytes
+                    64 =>   262,144 bytes
+                    32 =>   131,072 bytes
+                    16 =>    65,536 bytes
+                     8 =>    32,768 bytes : for low-latency (*default)
+
+config PREEMPT_NO_MUNMAP_RANGE
+	int "Memory unmap unit on non-preempt mode (1024 => 4MB)"
+	depends on PREEMPT_NONE
+	range 8 2048
+	default 1024
+	help
+
+	  unmap_vmas(= unmap a range of memory covered by a list of vma) is
+	  treading a delicate and uncomfortable line between high performance
+	  and low latency.
+	  This option improves performance at the expense of latency.
+
+	  So although there may be no need to reschedule right now,
+	  if we keep on gathering more and more memory without flushing,
+	  we'll be very unresponsive when a reschedule is needed later on.
+
+	  Consider the best suitable result between high performance and
+	  low latency on non-preempt mode. Select optimal munmap size to return
+	  memory space that is allocated by mmap system call.
+
+	  This value can be changed after boot using the
+	  /proc/sys/vm/munmap_unit_size tunable.
+
+	  Examples:
+                  2048 => 8,388,608 bytes : for straight-line efficiency
+                  1024 => 4,194,304 bytes (*default)
+                   512 => 2,097,152 bytes
+                   256 => 1,048,576 bytes
+                   128 =>   524,288 bytes
+                    64 =>   262,144 bytes
+                    32 =>   131,072 bytes
+                    16 =>    65,536 bytes
+                     8 =>    32,768 bytes : for low-latency
+
 #
 # Architectures with an unreliable sched_clock() should select this:
 #
-- 
1.7.3.4

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