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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1309182116-26698-4-git-send-email-leemgs1@gmail.com>
Date:	Mon, 27 Jun 2011 22:41:55 +0900
From:	Geunsik Lim <leemgs1@...il.com>
To:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Hugh Dickins <hughd@...gle.com>,
	Steven Rostedt <rostedt@...dmis.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Darren Hart <dvhart@...ux.intel.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>
Subject: [PATCH V2 3/4] munmap: kbuild menu for munmap interface

From: Geunsik Lim <geunsik.lim@...sung.com>

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

Signed-off-by: Geunsik Lim <geunsik.lim@...sung.com>
Acked-by: Hyunjin Choi <hj89.choi@...sung.com>
CC: Andrew Morton <akpm@...ux-foundation.org>
CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC: Steven Rostedt <rostedt@...hat.com>
CC: Hugh Dickins <hughd@...gle.com>
CC: Randy Dunlap <randy.dunlap@...cle.com>
CC: Ingo Molnar <mingo@...e.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

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