• H
    [PATCH] mm: update_hiwaters just in time · 365e9c87
    Hugh Dickins 提交于
    update_mem_hiwater has attracted various criticisms, in particular from those
    concerned with mm scalability.  Originally it was called whenever rss or
    total_vm got raised.  Then many of those callsites were replaced by a timer
    tick call from account_system_time.  Now Frank van Maarseveen reports that to
    be found inadequate.  How about this?  Works for Frank.
    
    Replace update_mem_hiwater, a poor combination of two unrelated ops, by macros
    update_hiwater_rss and update_hiwater_vm.  Don't attempt to keep
    mm->hiwater_rss up to date at timer tick, nor every time we raise rss (usually
    by 1): those are hot paths.  Do the opposite, update only when about to lower
    rss (usually by many), or just before final accounting in do_exit.  Handle
    mm->hiwater_vm in the same way, though it's much less of an issue.  Demand
    that whoever collects these hiwater statistics do the work of taking the
    maximum with rss or total_vm.
    
    And there has been no collector of these hiwater statistics in the tree.  The
    new convention needs an example, so match Frank's usage by adding a VmPeak
    line above VmSize to /proc/<pid>/status, and also a VmHWM line above VmRSS
    (High-Water-Mark or High-Water-Memory).
    
    There was a particular anomaly during mremap move, that hiwater_vm might be
    captured too high.  A fleeting such anomaly remains, but it's quickly
    corrected now, whereas before it would stick.
    
    What locking?  None: if the app is racy then these statistics will be racy,
    it's not worth any overhead to make them exact.  But whenever it suits,
    hiwater_vm is updated under exclusive mmap_sem, and hiwater_rss under
    page_table_lock (for now) or with preemption disabled (later on): without
    going to any trouble, minimize the time between reading current values and
    updating, to minimize those occasions when a racing thread bumps a count up
    and back down in between.
    Signed-off-by: NHugh Dickins <hugh@veritas.com>
    Signed-off-by: NAndrew Morton <akpm@osdl.org>
    Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
    365e9c87
exec.c 34.5 KB