Re: Memory overcommit
From: David Rientjes
Date: Tue Nov 03 2009 - 20:58:18 EST
On Wed, 4 Nov 2009, KAMEZAWA Hiroyuki wrote:
> > That's a different point. Today, we can influence the badness score of
> > any user thread to prioritize oom killing from userspace and that can be
> > done regardless of whether there's a memory leaker, a fork bomber, etc.
> > The priority based oom killing is important to production scenarios and
> > cannot be replaced by a heuristic that works everytime if it cannot be
> > influenced by userspace.
> I don't removed oom_adj...
Right, but we must ensure that we have the same ability to influence a
priority based oom killing scheme from userspace as we currently do with a
relatively static total_vm. total_vm may not be the optimal baseline, but
it does allow users to tune oom_adj specifically to identify tasks that
are using more memory than expected and to be static enough to not depend
on rss, for example, that is really hard to predict at the time of oom.
That's actually my main goal in this discussion: to avoid losing any
ability of userspace to influence to priority of tasks being oom killed
(if you haven't noticed :).
> > Tweaking on the heuristic will probably make it more convoluted and
> > overall worse, I agree. But it's a more stable baseline than rss from
> > which we can set oom killing priorities from userspace.
> - "rss < total_vm_size" always.
But rss is much more dynamic than total_vm, that's my point.
> - oom_adj culculation is quite strong.
> - total_vm of processes which maps hugetlb is very big ....but killing them
> is no help for usual oom.
> I recommend you to add "stable baseline" knob for user space, as I wrote.
> My patch 6 adds stable baseline bonus as 50% of vm size if run_time is enough
There's no clear relationship between VM size and runtime. The forkbomb
heuristic itself could easily return a badness of ULONG_MAX if one is
detected using runtime and number of children, as I earlier proposed, but
that doesn't seem helpful to factor into the scoring.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/