lkml.org 
[lkml]   [2012]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module
    On Thu, 12 Jan 2012, leonid.moiseichuk@nokia.com wrote:

    > As I wrote the proposed change is not safety belt but looking ahead
    > radar.
    > If it detects that we are close to wall it starts to alarm and alarm
    > volume is proportional to distance.
    >

    Then it's fundamentally flawed since there's no guarantee that coming with
    100MB of the min watermark, for example, means that an oom is imminent and
    will just result in unnecessary notification to userspace that will cause
    some action to be taken that may not be necessary. If the setting of
    these thresholds depends on some pattern that is guaranteed to be along
    the path to oom for a certain workload, then that will also change
    depending on VM implementation changes, kernel versions, other
    applications, etc., and simply is unmaintainable.

    > In close-to-OOM situations device becomes very slow, which is not good
    > for user. The performance difference depends on code size and storage
    > performance to trash code pages but even 20% is noticeable. Practically
    > 2x-5x times slowdown was observed.
    >

    It would be much better to address the slowdown when running out of memory
    rather than requiring userspace to react and unnecessarily send signals to
    threads that may or may not have the ability to respond because they may
    already be oom themselves. You can do crazy things to reduce latency in
    lowmem memory allocations like changing gfp_allowed_mask to be GFP_ATOMIC
    so that direct reclaim is never called, for example, and then use the
    proposed oom killer delay to handle the situation at the time of oom.

    Regardless, you should be addressing the slowness in lowmem situations
    rather than implementing notifiers to userspace to handle the events
    itself, so nack on this proposal.


    \
     
     \ /
      Last update: 2012-01-12 21:57    [W:3.483 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site