lkml.org 
[lkml]   [2016]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/3] mm, oom: protect !costly allocations some more
    On Fri 11-03-16 11:08:05, Hugh Dickins wrote:
    > On Fri, 11 Mar 2016, Michal Hocko wrote:
    > > On Fri 11-03-16 04:17:30, Hugh Dickins wrote:
    > > > On Wed, 9 Mar 2016, Michal Hocko wrote:
    > > > > Joonsoo has pointed out that this attempt is still not sufficient
    > > > > becasuse we might have invoked only a single compaction round which
    > > > > is might be not enough. I fully agree with that. Here is my take on
    > > > > that. It is again based on the number of retries loop.
    > > > >
    > > > > I was also playing with an idea of doing something similar to the
    > > > > reclaim retry logic:
    > > > > if (order) {
    > > > > if (compaction_made_progress(compact_result)
    > > > > no_compact_progress = 0;
    > > > > else if (compaction_failed(compact_result)
    > > > > no_compact_progress++;
    > > > > }
    > > > > but it is compaction_failed() part which is not really
    > > > > straightforward to define. Is it COMPACT_NO_SUITABLE_PAGE
    > > > > resp. COMPACT_NOT_SUITABLE_ZONE sufficient? compact_finished and
    > > > > compaction_suitable however hide this from compaction users so it
    > > > > seems like we can never see it.
    > > > >
    > > > > Maybe we can update the feedback mechanism from the compaction but
    > > > > retries count seems reasonably easy to understand and pragmatic. If
    > > > > we cannot form a order page after we tried for N times then it really
    > > > > doesn't make much sense to continue and we are oom for this order. I am
    > > > > holding my breath to hear from Hugh on this, though.
    > > >
    > > > Never a wise strategy. But I just got around to it tonight.
    > > >
    > > > I do believe you've nailed it with this patch! Thank you!
    > >
    > > That's a great news! Thanks for testing.
    > >
    > > > I've applied 1/3, 2/3 and this (ah, it became the missing 3/3 later on)
    > > > on top of 4.5.0-rc5-mm1 (I think there have been a couple of mmotms since,
    > > > but I've not got to them yet): so far it is looking good on all machines.
    > > >
    > > > After a quick go with the simple make -j20 in tmpfs, which survived
    > > > a cycle on the laptop, I've switched back to my original tougher load,
    > > > and that's going well so far: no sign of any OOMs. But I've interrupted
    > > > on the laptop to report back to you now, then I'll leave it running
    > > > overnight.
    > >
    > > OK, let's wait for the rest of the tests but I find it really optimistic
    > > considering how easily you could trigger the issue previously. Anyway
    > > I hope for your Tested-by after you are reasonably confident your loads
    > > are behaving well.
    >
    > Three have been stably running load for between 6 and 7 hours now,
    > no problems, looking very good:
    >
    > Tested-by: Hugh Dickins <hughd@google.com>

    Thanks!

    > I'll be interested to see how my huge tmpfs loads fare with the rework,
    > but I'm not quite ready to try that today; and any issue there (I've no
    > reason to suppose that there will be) can be a separate investigation
    > for me to make at some future date. It was this order=2 regression
    > that was holding me back, and I've now no objection to your patches
    > (though nobody should imagine that I've actually studied them).

    I still have some work on top pending and I do not want to rush these
    changes and target this for 4.7. 4.6 is just too close and I would hate
    to push some last minute changes. I think oom_reaper would be large
    enough for 4.6 in this area.

    I will post the full series after rc1. Andrew feel free to drop it from
    the mmotm tree for now. I would prefer they got all reviewed together
    rather than a larger number of fixups.

    Thanks Hugh for your testing. I wish I could depend on it less but I've
    not been able to reproduce not matter how much I tried.

    --
    Michal Hocko
    SUSE Labs

    \
     
     \ /
      Last update: 2016-03-14 18:01    [W:4.211 / U:0.324 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site