* [PATCH v2] mm: memcg: yield cpu when we fail to charge pages
@ 2020-09-08 20:14 Julius Hemanth Pitti
[not found] ` <20200908201426.14837-1-jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Julius Hemanth Pitti @ 2020-09-08 20:14 UTC (permalink / raw)
To: hannes, mhocko, vdavydov.dev, akpm, guro
Cc: cgroups, linux-mm, linux-kernel, xe-linux-external,
Julius Hemanth Pitti
For non root CG, in try_charge(), we keep trying
to charge until we succeed. On non-preemptive
kernel, when we are OOM, this results in holding
CPU forever.
On SMP systems, this doesn't create a big problem
because oom_reaper get a change to kill victim
and make some free pages. However on a single-core
CPU (or cases where oom_reaper pinned to same CPU
where try_charge is executing), oom_reaper shall
never get scheduled and we stay in try_charge forever.
Steps to repo this on non-smp:
1. mount -t tmpfs none /sys/fs/cgroup
2. mkdir /sys/fs/cgroup/memory
3. mount -t cgroup none /sys/fs/cgroup/memory -o memory
4. mkdir /sys/fs/cgroup/memory/0
5. echo 40M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes
6. echo $$ > /sys/fs/cgroup/memory/0/tasks
7. stress -m 5 --vm-bytes 10M --vm-hang 0
Signed-off-by: Julius Hemanth Pitti <jpitti@cisco.com>
Acked-by: Roman Gushchin <guro@fb.com>
---
Changes in v2:
- Added comments.
- Added "Acked-by: Roman Gushchin <guro@fb.com>".
---
mm/memcontrol.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cfa6cbad21d5..4f293bf8c7ed 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2745,6 +2745,15 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
if (fatal_signal_pending(current))
goto force;
+ /*
+ * We failed to charge even after retries, give oom_reaper or
+ * other process a change to make some free pages.
+ *
+ * On non-preemptive, Non-SMP system, this is critical, else
+ * we keep retrying with no success, forever.
+ */
+ cond_resched();
+
/*
* keep retrying as long as the memcg oom killer is able to make
* a forward progress or bypass the charge if the oom killer
--
2.17.1
^ permalink raw reply related [flat|nested] 4+ messages in thread[parent not found: <20200908201426.14837-1-jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH v2] mm: memcg: yield cpu when we fail to charge pages [not found] ` <20200908201426.14837-1-jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> @ 2020-09-08 20:31 ` Yang Shi [not found] ` <CAHbLzkqYrkA6=RSBpwEQJ5WaLUWwdP=05BPE2F4pRgk98NuVTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 4+ messages in thread From: Yang Shi @ 2020-09-08 20:31 UTC (permalink / raw) To: Julius Hemanth Pitti Cc: Johannes Weiner, Michal Hocko, Vladimir Davydov, Andrew Morton, Roman Gushchin, Cgroups, Linux MM, Linux Kernel Mailing List, xe-linux-external-FYB4Gu1CFyUAvxtiuMwx3w On Tue, Sep 8, 2020 at 1:14 PM Julius Hemanth Pitti <jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote: > > For non root CG, in try_charge(), we keep trying > to charge until we succeed. On non-preemptive > kernel, when we are OOM, this results in holding > CPU forever. > > On SMP systems, this doesn't create a big problem > because oom_reaper get a change to kill victim > and make some free pages. However on a single-core > CPU (or cases where oom_reaper pinned to same CPU > where try_charge is executing), oom_reaper shall > never get scheduled and we stay in try_charge forever. > > Steps to repo this on non-smp: > 1. mount -t tmpfs none /sys/fs/cgroup > 2. mkdir /sys/fs/cgroup/memory > 3. mount -t cgroup none /sys/fs/cgroup/memory -o memory > 4. mkdir /sys/fs/cgroup/memory/0 > 5. echo 40M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes > 6. echo $$ > /sys/fs/cgroup/memory/0/tasks > 7. stress -m 5 --vm-bytes 10M --vm-hang 0 Isn't it the same problem solved by e3336cab2579 ("mm: memcg: fix memcg reclaim soft lockup")? It has been in Linus's tree. > > Signed-off-by: Julius Hemanth Pitti <jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> > Acked-by: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> > --- > > Changes in v2: > - Added comments. > - Added "Acked-by: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>". > --- > mm/memcontrol.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index cfa6cbad21d5..4f293bf8c7ed 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2745,6 +2745,15 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, > if (fatal_signal_pending(current)) > goto force; > > + /* > + * We failed to charge even after retries, give oom_reaper or > + * other process a change to make some free pages. > + * > + * On non-preemptive, Non-SMP system, this is critical, else > + * we keep retrying with no success, forever. > + */ > + cond_resched(); > + > /* > * keep retrying as long as the memcg oom killer is able to make > * a forward progress or bypass the charge if the oom killer > -- > 2.17.1 > > ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAHbLzkqYrkA6=RSBpwEQJ5WaLUWwdP=05BPE2F4pRgk98NuVTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2] mm: memcg: yield cpu when we fail to charge pages [not found] ` <CAHbLzkqYrkA6=RSBpwEQJ5WaLUWwdP=05BPE2F4pRgk98NuVTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2020-09-08 20:53 ` Michal Hocko 2020-09-08 20:57 ` Julius Hemanth Pitti (jpitti) 1 sibling, 0 replies; 4+ messages in thread From: Michal Hocko @ 2020-09-08 20:53 UTC (permalink / raw) To: Yang Shi Cc: Julius Hemanth Pitti, Johannes Weiner, Vladimir Davydov, Andrew Morton, Roman Gushchin, Cgroups, Linux MM, Linux Kernel Mailing List, xe-linux-external-FYB4Gu1CFyUAvxtiuMwx3w On Tue 08-09-20 13:31:51, Yang Shi wrote: > On Tue, Sep 8, 2020 at 1:14 PM Julius Hemanth Pitti <jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote: > > > > For non root CG, in try_charge(), we keep trying > > to charge until we succeed. On non-preemptive > > kernel, when we are OOM, this results in holding > > CPU forever. > > > > On SMP systems, this doesn't create a big problem > > because oom_reaper get a change to kill victim > > and make some free pages. However on a single-core > > CPU (or cases where oom_reaper pinned to same CPU > > where try_charge is executing), oom_reaper shall > > never get scheduled and we stay in try_charge forever. > > > > Steps to repo this on non-smp: > > 1. mount -t tmpfs none /sys/fs/cgroup > > 2. mkdir /sys/fs/cgroup/memory > > 3. mount -t cgroup none /sys/fs/cgroup/memory -o memory > > 4. mkdir /sys/fs/cgroup/memory/0 > > 5. echo 40M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes > > 6. echo $$ > /sys/fs/cgroup/memory/0/tasks > > 7. stress -m 5 --vm-bytes 10M --vm-hang 0 > > Isn't it the same problem solved by e3336cab2579 ("mm: memcg: fix > memcg reclaim soft lockup")? It has been in Linus's tree. Yes it should because it adds a scheduling point regardless of reclaimability. > > Signed-off-by: Julius Hemanth Pitti <jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> > > Acked-by: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> > > --- > > > > Changes in v2: > > - Added comments. > > - Added "Acked-by: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>". > > --- > > mm/memcontrol.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index cfa6cbad21d5..4f293bf8c7ed 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2745,6 +2745,15 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, > > if (fatal_signal_pending(current)) > > goto force; > > > > + /* > > + * We failed to charge even after retries, give oom_reaper or > > + * other process a change to make some free pages. > > + * > > + * On non-preemptive, Non-SMP system, this is critical, else > > + * we keep retrying with no success, forever. > > + */ > > + cond_resched(); > > + > > /* > > * keep retrying as long as the memcg oom killer is able to make > > * a forward progress or bypass the charge if the oom killer > > -- > > 2.17.1 > > > > -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] mm: memcg: yield cpu when we fail to charge pages [not found] ` <CAHbLzkqYrkA6=RSBpwEQJ5WaLUWwdP=05BPE2F4pRgk98NuVTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2020-09-08 20:53 ` Michal Hocko @ 2020-09-08 20:57 ` Julius Hemanth Pitti (jpitti) 1 sibling, 0 replies; 4+ messages in thread From: Julius Hemanth Pitti (jpitti) @ 2020-09-08 20:57 UTC (permalink / raw) To: shy828301-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, xe-linux-external(mailer list), mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, guro-b10kYP2dOMg@public.gmane.org On Tue, 2020-09-08 at 13:31 -0700, Yang Shi wrote: > On Tue, Sep 8, 2020 at 1:14 PM Julius Hemanth Pitti <jpitti@cisco.com > > wrote: > > > > For non root CG, in try_charge(), we keep trying > > to charge until we succeed. On non-preemptive > > kernel, when we are OOM, this results in holding > > CPU forever. > > > > On SMP systems, this doesn't create a big problem > > because oom_reaper get a change to kill victim > > and make some free pages. However on a single-core > > CPU (or cases where oom_reaper pinned to same CPU > > where try_charge is executing), oom_reaper shall > > never get scheduled and we stay in try_charge forever. > > > > Steps to repo this on non-smp: > > 1. mount -t tmpfs none /sys/fs/cgroup > > 2. mkdir /sys/fs/cgroup/memory > > 3. mount -t cgroup none /sys/fs/cgroup/memory -o memory > > 4. mkdir /sys/fs/cgroup/memory/0 > > 5. echo 40M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes > > 6. echo $$ > /sys/fs/cgroup/memory/0/tasks > > 7. stress -m 5 --vm-bytes 10M --vm-hang 0 > > Isn't it the same problem solved by e3336cab2579 ("mm: memcg: fix > memcg reclaim soft lockup")? It has been in Linus's tree. Yes, indeed. I just tested with e3336cab2579, and it solved this problem. Thanks for pointing it out. > > > > > Signed-off-by: Julius Hemanth Pitti <jpitti@cisco.com> > > Acked-by: Roman Gushchin <guro@fb.com> > > --- > > > > Changes in v2: > > - Added comments. > > - Added "Acked-by: Roman Gushchin <guro@fb.com>". > > --- > > mm/memcontrol.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index cfa6cbad21d5..4f293bf8c7ed 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2745,6 +2745,15 @@ static int try_charge(struct mem_cgroup > > *memcg, gfp_t gfp_mask, > > if (fatal_signal_pending(current)) > > goto force; > > > > + /* > > + * We failed to charge even after retries, give oom_reaper > > or > > + * other process a change to make some free pages. > > + * > > + * On non-preemptive, Non-SMP system, this is critical, > > else > > + * we keep retrying with no success, forever. > > + */ > > + cond_resched(); > > + > > /* > > * keep retrying as long as the memcg oom killer is able to > > make > > * a forward progress or bypass the charge if the oom > > killer > > -- > > 2.17.1 > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-08 20:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-08 20:14 [PATCH v2] mm: memcg: yield cpu when we fail to charge pages Julius Hemanth Pitti
[not found] ` <20200908201426.14837-1-jpitti-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2020-09-08 20:31 ` Yang Shi
[not found] ` <CAHbLzkqYrkA6=RSBpwEQJ5WaLUWwdP=05BPE2F4pRgk98NuVTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-09-08 20:53 ` Michal Hocko
2020-09-08 20:57 ` Julius Hemanth Pitti (jpitti)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox