lkml.org 
[lkml]   [2011]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH V2 3/4] munmap: kbuild menu for munmap interface
Date
From: Geunsik Lim <geunsik.lim@samsung.com>

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

Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
Acked-by: Hyunjin Choi <hj89.choi@samsung.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Steven Rostedt <rostedt@redhat.com>
CC: Hugh Dickins <hughd@google.com>
CC: Randy Dunlap <randy.dunlap@oracle.com>
CC: Ingo Molnar <mingo@elte.hu>
---
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


\
 
 \ /
  Last update: 2011-06-27 15:45    [from the cache]
©2003-2011 Jasper Spaans