lkml.org 
[lkml]   [2011]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] Unmapped page cache control (v5)
    On 04/01/2011 09:17 AM, KOSAKI Motohiro wrote:
    > Hi Christoph,
    >
    > Thanks, long explanation.
    >
    >
    >> On Thu, 31 Mar 2011, KOSAKI Motohiro wrote:
    >>
    >>> 1) zone reclaim doesn't work if the system has multiple node and the
    >>> workload is file cache oriented (eg file server, web server, mail server, et al).
    >>> because zone recliam make some much free pages than zone->pages_min and
    >>> then new page cache request consume nearest node memory and then it
    >>> bring next zone reclaim. Then, memory utilization is reduced and
    >>> unnecessary LRU discard is increased dramatically.
    >>
    >> That is only true if the webserver only allocates from a single node. If
    >> the allocation load is balanced then it will be fine. It is useful to
    >> reclaim pages from the node where we allocate memory since that keeps the
    >> dataset node local.
    >
    > Why?
    > Scheduler load balancing only consider cpu load. Then, usually memory
    > pressure is no complete symmetric. That's the reason why we got the
    > bug report periodically.

    Agreed. As Christoph said if the allocation load is balanced it will be fine.
    But I think it's not always true that the allocation load is balanced.

    >>> But, I agree that now we have to concern slightly large VM change parhaps
    >>> (or parhaps not). Ok, it's good opportunity to fill out some thing.
    >>> Historically, Linux MM has "free memory are waste memory" policy, and It
    >>> worked completely fine. But now we have a few exceptions.
    >>>
    >>> 1) RT, embedded and finance systems. They really hope to avoid reclaim
    >>> latency (ie avoid foreground reclaim completely) and they can accept
    >>> to make slightly much free pages before memory shortage.
    >>
    >> In general we need a mechanism to ensure we can avoid reclaim during
    >> critical sections of application. So some way to give some hints to the
    >> machine to free up lots of memory (/proc/sys/vm/dropcaches is far too
    >> drastic) may be useful.
    >
    > Exactly.
    > I've heard multiple times this request from finance people. And I've also
    > heared the same request from bullet train control software people recently.

    I completely agree with you. I have both customers and they really need it
    to make their critical section deterministic.

    Thanks,
    Satoru


    \
     
     \ /
      Last update: 2011-04-02 01:13    [W:0.042 / U:2.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site