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

[Geunsik Lim]

On Tue, Apr 26, 2011 at 12:45 AM, Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote:
> On Mon, 25 Apr 2011 19:44:31 +0900 Geunsik Lim wrote:
>
>> 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>
>> ---
>> Â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
>
> Â Â Â Â Âunmap_vmas (= unmap a range ...
>
>> + Â Â Â a delicate and uncomfortable line between hi-performance and low-latency.
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âhigh performane and low latency.
>
>> + Â Â Â We've chosen to improve performance at the expense of latency.
>
> Â Â Â Â ÂThis option improves performance at the expense of latency.
>
>> +
>> + Â Â Â So although there may be no need to resched right now,
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âreschedule
>
>> + Â Â Â if we keep on gathering more and more without flushing,
>
> Â Â Â Â Â Â Â Â Â Â Â Âgathering more and more <what> ?
>
>> + Â Â Â we'll be very unresponsive when a resched is needed later on.
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âreschedule
>
>> +
>> + Â Â Â 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
>
> Â Â Â Â Â Â Â Â Â Â Â for
>
>> + Â Â Â with 100MB for recording in embedded devices, we have to wait for more than 3seconds to
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â3 seconds
>
> (but try not to put text over 80 columns, please)
>
>> + Â Â Â 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.
>
> Indent above with tab + 2 spaces.
>
>> +
>> + Â Â Â 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)
>
> All of above would be better with added space before "bytes", as, e.g.:
> Â Â Â Â Â Â Â Â Â Â Â Â8 => Â Â32,768 bytes
>
>> +
>> +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
>
> Â Â Â Â Âunmap_vmas (= unmap
>
>> + Â Â Â a delicate and uncomfortable line between hi-performance and low-latency.
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âhigh performance and low latency.
>
>> + Â Â Â We've chosen to improve performance at the expense of latency.
>
> Â Â Â Â ÂThis option improves performance at the expense of latency.
>
>> +
>> + Â Â Â So although there may be no need to resched right now,
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âreschedule
>
>> + Â Â Â if we keep on gathering more and more without flushing,
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âmore and more what?
>
>> + Â Â Â we'll be very unresponsive when a resched is needed later on.
>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âreschedule
>
>> +
>> + Â Â Â Consider the best suitable result between high performance and low latency
>> + Â Â Â on preemption mode.
>
> but this option is for non-preempt mode... so should that text above be modified?
>
>> + Â Â Â 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.
>
> Indent above with tab + 2 spaces.
>
>> +
>> + Â Â Â 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
>
> Â Â Â Â Â Â Â ÂUse space before "bytes" in table above, please.
>
>> +
>> Â#
>> Â# Architectures with an unreliable sched_clock() should select this:
>> Â#
>
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
Randy Dunlap. Thanks a lot.
I will modify contents that you commented.
>



-- 
Regards,
Geunsik Lim ( Samsung Electronics )
Blog : http://blog.naver.com/invain/
e-Mail: geunsik.lim@xxxxxxxxxxx
    Â leemgs@xxxxxxxxx , leemgs1@xxxxxxxxx
--
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/
--
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/