[lkml]   [2011]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCH -v2 -mm] add extra free kbytes tunable
    On 09/01/2011 05:58 PM, Andrew Morton wrote:
    > On Thu, 1 Sep 2011 15:26:50 -0400
    > Rik van Riel <> wrote:
    >> Add a userspace visible knob
    > argh. Fear and hostility at new knobs which need to be maintained for
    > ever, even if the underlying implementation changes.
    > Unfortunately, this one makes sense.
    >> to tell the VM to keep an extra amount of memory free, by increasing
    >> the gap between each zone's min and low watermarks.
    >> This is useful for realtime applications that call system calls and
    >> have a bound on the number of allocations that happen in any short
    >> time period. In this application, extra_free_kbytes would be left at
    >> an amount equal to or larger than the maximum number of
    >> allocations that happen in any burst.
    > _is_ it useful? Proof?
    > Who is requesting this? Have they tested it? Results?

    This is interesting for me.

    Some of our customers have realtime applications and they are concerned
    the fact that Linux uses free memory as pagecache. It means that
    when their application allocate memory, Linux kernel tries to reclaim
    memory at first and then allocate it. This may make memory allocation
    latency bigger.

    In many cases this is not a big issue because Linux has kswapd for
    background reclaim and it is fast enough not to enter direct reclaim
    path if there are a lot of clean cache. But under some situations -
    e.g. Application allocates a lot of memory which is larger than delta
    between watermark_low and watermark_min in a short time and kswapd
    can't reclaim fast enough due to dirty page reclaim, direct reclaim
    is executed and causes big latency.

    We can avoid the issue above by using preallocation and mlock.
    But it can't cover kmalloc used in systemcall. So I'd like to use
    this patch with mlock to avoid memory allocation latency issue as
    low as possible. It may not be a perfect solution but it is important
    for customers in enterprise area to configure the amount of free
    memory at their own risk.

    Anyway, now I'm testing this patch and will report a test result later.


     \ /
      Last update: 2011-09-02 19:19    [W:0.023 / U:32.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site