From: Michal Hocko <firstname.lastname@example.org> To: David Rientjes <email@example.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, Roman Gushchin <firstname.lastname@example.org>, email@example.com, Andrew Morton <firstname.lastname@example.org>, LKML <email@example.com> Subject: Re: [RFC PATCH v2 0/3] oom: rework oom_reaper vs. exit_mmap handoff Date: Thu, 8 Nov 2018 10:32:24 +0100 [thread overview] Message-ID: <20181108093224.GS27423@dhcp22.suse.cz> (raw) In-Reply-To: <firstname.lastname@example.org> On Thu 25-10-18 10:24:00, Michal Hocko wrote: > The previous version of this RFC has been posted here . I have fixed > few issues spotted during the review and by 0day bot. I have also reworked > patch 2 to be ratio rather than an absolute number based. > > With this series applied the locking protocol between the oom_reaper and > the exit path is as follows. > > All parts which cannot race should use the exclusive lock on the exit > path. Once the exit path has passed the moment when no blocking locks > are taken then it clears mm->mmap under the exclusive lock. oom_reaper > checks for this and sets MMF_OOM_SKIP only if the exit path is not guaranteed > to finish the job. This is patch 3 so see the changelog for all the details. > > I would really appreciate if David could give this a try and see how > this behaves in workloads where the oom_reaper falls flat now. I have > been playing with sparsely allocated memory with a high pte/real memory > ratio and large mlocked processes and it worked reasonably well. Does this help workloads you were referring to earlier David? > There is still some room for tuning here of course. We can change the > number of retries for the oom_reaper as well as the threshold when the > keep retrying. > > Michal Hocko (3): > mm, oom: rework mmap_exit vs. oom_reaper synchronization > mm, oom: keep retrying the oom_reap operation as long as there is substantial memory left > mm, oom: hand over MMF_OOM_SKIP to exit path if it is guranteed to finish > > Diffstat: > include/linux/oom.h | 2 -- > mm/internal.h | 3 +++ > mm/memory.c | 28 ++++++++++++++-------- > mm/mmap.c | 69 +++++++++++++++++++++++++++++++++-------------------- > mm/oom_kill.c | 45 ++++++++++++++++++++++++---------- > 5 files changed, 97 insertions(+), 50 deletions(-) > >  http://email@example.com > -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2018-11-08 9:32 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-25 8:24 Michal Hocko 2018-10-25 8:24 ` [RFC PATCH v2 1/3] mm, oom: rework mmap_exit vs. oom_reaper synchronization Michal Hocko 2018-10-25 8:24 ` [RFC PATCH v2 2/3] mm, oom: keep retrying the oom_reap operation as long as there is substantial memory left Michal Hocko 2018-10-25 8:24 ` [RFC PATCH v2 3/3] mm, oom: hand over MMF_OOM_SKIP to exit path if it is guranteed to finish Michal Hocko 2018-10-30 4:45 ` Tetsuo Handa 2018-10-30 6:31 ` Michal Hocko 2018-10-30 9:47 ` Tetsuo Handa 2018-10-30 11:39 ` Michal Hocko 2018-10-30 12:02 ` Tetsuo Handa 2018-10-30 12:10 ` Michal Hocko 2018-10-30 13:57 ` Tetsuo Handa 2018-10-30 14:23 ` Michal Hocko 2018-11-08 9:32 ` Michal Hocko [this message] 2018-11-14 9:46 ` [RFC PATCH v2 0/3] oom: rework oom_reaper vs. exit_mmap handoff Tetsuo Handa 2018-11-14 10:16 ` Michal Hocko 2018-11-15 9:54 ` Tetsuo Handa 2018-11-15 11:36 ` Michal Hocko 2018-11-16 10:06 ` Tetsuo Handa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181108093224.GS27423@dhcp22.suse.cz \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --email@example.com \ --subject='Re: [RFC PATCH v2 0/3] oom: rework oom_reaper vs. exit_mmap handoff' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).