From: Michal Hocko <mhocko@suse.com> To: Vasily Averin <vvs@virtuozzo.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Vladimir Davydov <vdavydov.dev@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH memcg] memcg: prohibit unconditional exceeding the limit of dying tasks Date: Mon, 13 Sep 2021 10:39:42 +0200 [thread overview] Message-ID: <YT8OTozT3FN9P2k7@dhcp22.suse.cz> (raw) In-Reply-To: <8b98d44a-aeb2-5f5f-2545-ac2bd0c7049b@virtuozzo.com> On Mon 13-09-21 10:51:37, Vasily Averin wrote: > On 9/10/21 3:39 PM, Vasily Averin wrote: > > The kernel currently allows dying tasks to exceed the memcg limits. > > The allocation is expected to be the last one and the occupied memory > > will be freed soon. > > This is not always true because it can be part of the huge vmalloc > > allocation. Allowed once, they will repeat over and over again. > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 389b5766e74f..67195fcfbddf 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2622,15 +2625,6 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, > > if (gfp_mask & __GFP_ATOMIC) > > goto force; > > > > - /* > > - * Unlike in global OOM situations, memcg is not in a physical > > - * memory shortage. Allow dying and OOM-killed tasks to > > - * bypass the last charges so that they can exit quickly and > > - * free their memory. > > - */ > > - if (unlikely(should_force_charge())) > > - goto force; > > - > > Should we keep current behaviour for (current->flags & PF_EXITING) case perhaps? Why? > It is set inside do_exit only and (I hope) cannot trigger huge vmalloc allocations. Allocations in this code path should be rare but it is not like they are non-existent. This is rather hard to review area spread at many places so if we are deciding to make the existing model simpler (no bypassing) then I would rather have no exceptions unless they are reaaly necessary and document them if they are. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org> To: Vasily Averin <vvs-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Vladimir Davydov <vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Tetsuo Handa <penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org>, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH memcg] memcg: prohibit unconditional exceeding the limit of dying tasks Date: Mon, 13 Sep 2021 10:39:42 +0200 [thread overview] Message-ID: <YT8OTozT3FN9P2k7@dhcp22.suse.cz> (raw) In-Reply-To: <8b98d44a-aeb2-5f5f-2545-ac2bd0c7049b-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org> On Mon 13-09-21 10:51:37, Vasily Averin wrote: > On 9/10/21 3:39 PM, Vasily Averin wrote: > > The kernel currently allows dying tasks to exceed the memcg limits. > > The allocation is expected to be the last one and the occupied memory > > will be freed soon. > > This is not always true because it can be part of the huge vmalloc > > allocation. Allowed once, they will repeat over and over again. > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 389b5766e74f..67195fcfbddf 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2622,15 +2625,6 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, > > if (gfp_mask & __GFP_ATOMIC) > > goto force; > > > > - /* > > - * Unlike in global OOM situations, memcg is not in a physical > > - * memory shortage. Allow dying and OOM-killed tasks to > > - * bypass the last charges so that they can exit quickly and > > - * free their memory. > > - */ > > - if (unlikely(should_force_charge())) > > - goto force; > > - > > Should we keep current behaviour for (current->flags & PF_EXITING) case perhaps? Why? > It is set inside do_exit only and (I hope) cannot trigger huge vmalloc allocations. Allocations in this code path should be rare but it is not like they are non-existent. This is rather hard to review area spread at many places so if we are deciding to make the existing model simpler (no bypassing) then I would rather have no exceptions unless they are reaaly necessary and document them if they are. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2021-09-13 8:39 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-10 12:39 [PATCH memcg] memcg: prohibit unconditional exceeding the limit of dying tasks Vasily Averin 2021-09-10 13:04 ` Tetsuo Handa 2021-09-10 13:04 ` Tetsuo Handa 2021-09-10 13:20 ` Vasily Averin 2021-09-10 13:20 ` Vasily Averin 2021-09-10 14:55 ` Michal Hocko 2021-09-13 8:29 ` Vasily Averin 2021-09-13 8:29 ` Vasily Averin 2021-09-13 8:42 ` Michal Hocko 2021-09-13 8:42 ` Michal Hocko 2021-09-17 8:06 ` [PATCH mm] vmalloc: back off when the current task is OOM-killed Vasily Averin 2021-09-17 8:06 ` Vasily Averin 2021-09-19 23:31 ` Andrew Morton 2021-09-19 23:31 ` Andrew Morton 2021-09-20 1:22 ` Tetsuo Handa 2021-09-20 10:59 ` Vasily Averin 2021-09-20 10:59 ` Vasily Averin 2021-09-21 18:55 ` Andrew Morton 2021-09-22 6:18 ` Vasily Averin 2021-09-22 12:27 ` Michal Hocko 2021-09-22 12:27 ` Michal Hocko 2021-09-23 6:49 ` Vasily Averin 2021-09-23 6:49 ` Vasily Averin 2021-09-24 7:55 ` Michal Hocko 2021-09-24 7:55 ` Michal Hocko 2021-09-27 9:36 ` Vasily Averin 2021-09-27 9:36 ` Vasily Averin 2021-09-27 11:08 ` Michal Hocko 2021-09-27 11:08 ` Michal Hocko 2021-10-05 13:52 ` [PATCH mm v2] " Vasily Averin 2021-10-05 13:52 ` Vasily Averin 2021-10-05 14:00 ` Vasily Averin 2021-10-05 14:00 ` Vasily Averin 2021-10-07 10:47 ` Michal Hocko 2021-10-07 10:47 ` Michal Hocko 2021-10-07 19:55 ` Andrew Morton 2021-10-07 19:55 ` Andrew Morton 2021-09-10 13:07 ` [PATCH memcg] memcg: prohibit unconditional exceeding the limit of dying tasks Vasily Averin 2021-09-10 13:07 ` Vasily Averin 2021-09-13 7:51 ` Vasily Averin 2021-09-13 7:51 ` Vasily Averin 2021-09-13 8:39 ` Michal Hocko [this message] 2021-09-13 8:39 ` Michal Hocko 2021-09-13 9:37 ` Vasily Averin 2021-09-13 9:37 ` Vasily Averin 2021-09-13 10:10 ` Michal Hocko 2021-09-13 10:10 ` Michal Hocko 2021-09-13 8:53 ` Michal Hocko 2021-09-13 10:35 ` Vasily Averin 2021-09-13 10:35 ` Vasily Averin 2021-09-13 10:55 ` Michal Hocko 2021-09-13 10:55 ` Michal Hocko 2021-09-14 10:01 ` Vasily Averin 2021-09-14 10:01 ` Vasily Averin 2021-09-14 10:10 ` [PATCH memcg v2] " Vasily Averin 2021-09-14 10:10 ` Vasily Averin 2021-09-16 12:55 ` Michal Hocko 2021-09-16 12:55 ` Michal Hocko 2021-10-05 13:52 ` [PATCH memcg v3] " Vasily Averin 2021-10-05 13:52 ` Vasily Averin 2021-10-05 14:55 ` Michal Hocko 2021-10-05 14:55 ` Michal Hocko
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=YT8OTozT3FN9P2k7@dhcp22.suse.cz \ --to=mhocko@suse.com \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=vdavydov.dev@gmail.com \ --cc=vvs@virtuozzo.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.