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    [W:0.027 / U:91.924 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site