lkml.org 
[lkml]   [2009]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux killed Kenny, bastard!
On Wed, 14 Jan 2009, Evgeniy Polyakov wrote:

> Out of curiousity, how feature can be used, if no one except hardcore
> kernel hackers know how to work with it? I do not insult, no, I'm really
> curious. This may explain, why admins I worked with about this issue did
> not fully succeeded with tuning.
>

You read the code.

It's always great to improve the documentation of a kernel feature, and I
agree that it certainly applies in this case.

I think you could also improve how the badness() scoring is implemented to
make it easier to predict from userspace. I doubt you would find much
opposition to improving the heuristic; we cannot, however, change
/proc/pid/oom_adj since it already has users who depend on it.

> > Being ignorant about cpusets doesn't justify you breaking their oom
> > handling.
>
> I did not break cpuset oom-handling, I provided a way to implement it
> differently to solve the problem. Yes, this may have side effects, if
> people care, they will not use the feature and leave victim name as NULL
> (although allowing Kenny to live breaks the absolute fundamentals).
> Those people who do need this functionality will work with it.
>

You're treating each oom constraint like they are on the same; in a
cpuset-constrained oom, which can be much more common than system-wide
unconstrained ooms, we want to target a task that will allow for future
memory freeing in that cpuset.

So in these cases, to avoid needlessly killing your victim, you would be
forced to set oom_victim_name to NULL. That's hardly useful if the same
problem you're trying to fix still exists both globally and within a
cpuset. Your patch doesn't address this use case, so it's already
incomplete.

In a mempolicy-constrained oom as the result of MPOL_BIND, which can also
be much more common than system-wide unconstrained ooms, we want to target
current because it has allocations from the bound nodes. Your patch
doesn't touch this path, so it's already inconsistent.

I'm comfortable that this patch will not be merged, so I'll silently point
to past posts for the duration of this thread. I definitely think the
documentation can be improved and I don't think you'll have any opposition
to sane heuristic changes that also rely on userspace input via
/proc/pid/oom_adj. Thank you for working on this!


\
 
 \ /
  Last update: 2009-01-14 01:35    [W:0.100 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site