| 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
| ||
|
Message-Id: <1303728272-11408-4-git-send-email-leemgs1@gmail.com>
Date: Mon, 25 Apr 2011 19:44:31 +0900
From: Geunsik Lim <leemgs1@...il.com>
To: Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Hugh Dickins <hughd@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Darren Hart <dvhart@...ux.intel.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-rt-users <linux-rt-users@...r.kernel.org>
Subject: [PATCH 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>
---
init/Kconfig | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mm/memory.c | 21 +++++++++++-----
2 files changed, 84 insertions(+), 7 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 56240e7..0983961 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -557,6 +557,76 @@ config LOG_BUF_SHIFT
13 => 8 KB
12 => 4 KB
+config PREEMPT_OK_MUNMAP_RANGE
+ int "Memory unmap unit on preemption 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 hi-performance and low-latency.
+ We've chosen to improve performance at the expense of latency.
+
+ So although there may be no need to resched right now,
+ if we keep on gathering more and more without flushing,
+ we'll be very unresponsive when a resched is needed later on.
+
+ Consider the best suitable result between high performance and low latency
+ on preemption 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 3seconds 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,608bytes : for straight-line efficiency
+ 1024 => 4,194,304bytes
+ 512 => 2,097,152bytes
+ 256 => 1,048,576bytes
+ 128 => 524,288bytes
+ 64 => 262,144bytes
+ 32 => 131,072bytes
+ 16 => 65,536bytes
+ 8 => 32,768bytes : for low-latency (*default)
+
+config PREEMPT_NO_MUNMAP_RANGE
+ int "Memory unmap unit on non-preemption 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 hi-performance and low-latency.
+ We've chosen to improve performance at the expense of latency.
+
+ So although there may be no need to resched right now,
+ if we keep on gathering more and more without flushing,
+ we'll be very unresponsive when a resched is needed later on.
+
+ Consider the best suitable result between high performance and low latency
+ on preemption 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,608bytes : for straight-line efficiency
+ 1024 => 4,194,304bytes (*default)
+ 512 => 2,097,152bytes
+ 256 => 1,048,576bytes
+ 128 => 524,288bytes
+ 64 => 262,144bytes
+ 32 => 131,072bytes
+ 16 => 65,536bytes
+ 8 => 32,768bytes : for low-latency
+
#
# Architectures with an unreliable sched_clock() should select this:
#
diff --git a/mm/memory.c b/mm/memory.c
index ce22a25..e4533fe 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -57,6 +57,7 @@
#include <linux/swapops.h>
#include <linux/elf.h>
#include <linux/gfp.h>
+#include <linux/munmap_unit_size.h>
#include <asm/io.h>
#include <asm/pgalloc.h>
@@ -1079,6 +1080,10 @@ static unsigned long unmap_page_range(struct mmu_gather *tlb,
(*zap_work)--;
continue;
}
+#if 0
+printk("DEBUG:munmap step2,(%s:%d), unmap range = current(%lu) + \
+zap_work(%lu bytes) \n", current->comm, current->pid, addr, *zap_work);
+#endif
next = zap_pud_range(tlb, vma, pgd, addr, next,
zap_work, details);
} while (pgd++, addr = next, (addr != end && *zap_work > 0));
@@ -1088,12 +1093,10 @@ static unsigned long unmap_page_range(struct mmu_gather *tlb,
return addr;
}
-#ifdef CONFIG_PREEMPT
-# define ZAP_BLOCK_SIZE (8 * PAGE_SIZE)
-#else
-/* No preempt: go for improved straight-line efficiency */
-# define ZAP_BLOCK_SIZE (1024 * PAGE_SIZE)
-#endif
+/* No preempt: go for improved straight-line efficiency
+ * on PREEMPT(preemption mode) this is not a critical latency-path.
+ */
+# define ZAP_BLOCK_SIZE (munmap_unit_size * PAGE_SIZE)
/**
* unmap_vmas - unmap a range of memory covered by a list of vma's
@@ -1133,7 +1136,11 @@ unsigned long unmap_vmas(struct mmu_gather **tlbp,
spinlock_t *i_mmap_lock = details? details->i_mmap_lock: NULL;
int fullmm = (*tlbp)->fullmm;
struct mm_struct *mm = vma->vm_mm;
-
+#if 0
+printk("DEBUG:munmap step1,(%s:%d), unit=zap_work(%ld)/ZAP_BLOCK(%ld), \
+vma:[%8lu]=%lu-%lu \n", current->comm, current->pid, zap_work, ZAP_BLOCK_SIZE, \
+vma->vm_end - vma->vm_start, vma->vm_end, vma->vm_start);
+#endif
mmu_notifier_invalidate_range_start(mm, start_addr, end_addr);
for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next) {
unsigned long end;
--
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/
Powered by blists - more mailing lists