lkml.org 
[lkml]   [2010]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [resend][PATCH 2/4] Revert "oom: deprecate oom_adj tunable"
    On Tue, 23 Nov 2010, KOSAKI Motohiro wrote:

    > > > No irrelevant. Your patch break their environment even though
    > > > they don't use oom_adj explicitly. because their application are using it.
    > > >
    > >
    > > The _only_ difference too oom_adj since the rewrite is that it is now
    > > mapped on a linear scale rather than an exponential scale.
    >
    > _only_ mean don't ZERO different. Why do userland application need to rewrite?
    >

    Because NOTHING breaks with the new mapping. Eight months later since
    this was initially proposed on linux-mm, you still cannot show a single
    example that depended on the exponential mapping of oom_adj. I'm not
    going to continue responding to your criticism about this point since your
    argument is completely and utterly baseless.

    > Again, IF you need to [0 .. 1000] range, you can calculate it by your
    > application. current oom score can be get from /proc/pid/oom_score and
    > total memory can be get from /proc/meminfo. You shouldn't have break
    > anything.
    >

    That would require the userspace tunable to be adjusted anytime a task's
    mempolicy changes, its nodemask changes, it's cpuset attachment changes,
    its mems change, a memcg limit changes, etc. The only constant is the
    task's priority, and the current oom_score_adj implementation preserves
    that unless explicitly changed later by the user. I completely understand
    that you may not have a use for this.


    \
     
     \ /
      Last update: 2010-11-28 02:45    [W:2.332 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site