lkml.org 
[lkml]   [2013]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [merged] mm-memcg-handle-non-error-oom-situations-more-gracefully.patch removed from -mm tree
    On Wed, Nov 27, 2013 at 07:20:37PM -0800, David Rientjes wrote:
    > On Wed, 27 Nov 2013, Johannes Weiner wrote:
    >
    > > > It appears as though this work is being developed in Linus's tree rather
    > > > than -mm, so I'm asking if we should consider backing some of it out for
    > > > 3.14 instead.
    > >
    > > The changes fix a deadlock problem. Are they creating problems that
    > > are worse than deadlocks, that would justify their revert?
    > >
    >
    > None that I am currently aware of, I'll continue to try them out. I'd
    > suggest just dropping the stable@kernel.org from the whole series though
    > unless there is another report of such a problem that people are running
    > into.

    The series has long been merged, how do we drop stable@kernel.org from
    it?

    > > Since we can't physically draw a perfect line, we should strive for a
    > > reasonable and intuitive line. After that it's rapidly diminishing
    > > returns. Killing something after that much reclaim effort without
    > > success is a completely reasonable and intuitive line to draw. It's
    > > also the line that has been drawn a long time ago and we're not
    > > breaking this because of a micro optmimization.
    > >
    >
    > You don't think something like this is helpful after scanning a memcg will
    > a large number of processes?
    >
    > We've had this patch internally since we started using memcg, it has
    > avoided some unnecessary oom killing.

    Do you have quantified data that OOM kills are reduced over a longer
    sampling period? How many kills are skipped? How many of them are
    deferred temporarily but the VM ended up having to kill something
    anyway? My theory still being that several loops of failed direct
    reclaim and charge attempts likely say more about the machine state
    than somebody randomly releasing some memory in the last minute...

    > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
    > --- a/mm/memcontrol.c
    > +++ b/mm/memcontrol.c
    > @@ -1836,6 +1836,13 @@ static void mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask,
    > if (!chosen)
    > return;
    > points = chosen_points * 1000 / totalpages;
    > +
    > + /* One last chance to see if we really need to kill something */
    > + if (mem_cgroup_margin(memcg) >= (1 << order)) {
    > + put_task_struct(chosen);
    > + return;
    > + }
    > +
    > oom_kill_process(chosen, gfp_mask, order, points, totalpages, memcg,
    > NULL, "Memory cgroup out of memory");
    > }


    \
     
     \ /
      Last update: 2013-11-28 05:41    [W:2.236 / U:0.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site