linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] memcg, oom: no oom-kill for __GFP_RETRY_MAYFAIL
@ 2019-04-28 23:56 Shakeel Butt
  2019-04-29 12:22 ` Michal Hocko
  0 siblings, 1 reply; 4+ messages in thread
From: Shakeel Butt @ 2019-04-28 23:56 UTC (permalink / raw)
  To: Johannes Weiner, Vladimir Davydov, Michal Hocko, Andrew Morton,
	Roman Gushchin
  Cc: linux-mm, cgroups, linux-kernel, Shakeel Butt

The documentation of __GFP_RETRY_MAYFAIL clearly mentioned that the
OOM killer will not be triggered and indeed the page alloc does not
invoke OOM killer for such allocations. However we do trigger memcg
OOM killer for __GFP_RETRY_MAYFAIL. Fix that.

Signed-off-by: Shakeel Butt <shakeelb@google.com>
---
 mm/memcontrol.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2713b45ec3f0..99eca724ed3b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2294,7 +2294,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
 	unsigned long nr_reclaimed;
 	bool may_swap = true;
 	bool drained = false;
-	bool oomed = false;
 	enum oom_status oom_status;
 
 	if (mem_cgroup_is_root(memcg))
@@ -2381,7 +2380,7 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
 	if (nr_retries--)
 		goto retry;
 
-	if (gfp_mask & __GFP_RETRY_MAYFAIL && oomed)
+	if (gfp_mask & __GFP_RETRY_MAYFAIL)
 		goto nomem;
 
 	if (gfp_mask & __GFP_NOFAIL)
@@ -2400,7 +2399,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
 	switch (oom_status) {
 	case OOM_SUCCESS:
 		nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
-		oomed = true;
 		goto retry;
 	case OOM_FAILED:
 		goto force;
-- 
2.21.0.593.g511ec345e18-goog


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] memcg, oom: no oom-kill for __GFP_RETRY_MAYFAIL
  2019-04-28 23:56 [PATCH] memcg, oom: no oom-kill for __GFP_RETRY_MAYFAIL Shakeel Butt
@ 2019-04-29 12:22 ` Michal Hocko
  2019-04-29 14:37   ` Shakeel Butt
  0 siblings, 1 reply; 4+ messages in thread
From: Michal Hocko @ 2019-04-29 12:22 UTC (permalink / raw)
  To: Shakeel Butt
  Cc: Johannes Weiner, Vladimir Davydov, Andrew Morton, Roman Gushchin,
	linux-mm, cgroups, linux-kernel

On Sun 28-04-19 16:56:13, Shakeel Butt wrote:
> The documentation of __GFP_RETRY_MAYFAIL clearly mentioned that the
> OOM killer will not be triggered and indeed the page alloc does not
> invoke OOM killer for such allocations. However we do trigger memcg
> OOM killer for __GFP_RETRY_MAYFAIL. Fix that.

An example of __GFP_RETRY_MAYFAIL memcg OOM report would be nice. I
thought we haven't been using that flag for memcg allocations yet.
But this is definitely good to have addressed.

> Signed-off-by: Shakeel Butt <shakeelb@google.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/memcontrol.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 2713b45ec3f0..99eca724ed3b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2294,7 +2294,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
>  	unsigned long nr_reclaimed;
>  	bool may_swap = true;
>  	bool drained = false;
> -	bool oomed = false;
>  	enum oom_status oom_status;
>  
>  	if (mem_cgroup_is_root(memcg))
> @@ -2381,7 +2380,7 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
>  	if (nr_retries--)
>  		goto retry;
>  
> -	if (gfp_mask & __GFP_RETRY_MAYFAIL && oomed)
> +	if (gfp_mask & __GFP_RETRY_MAYFAIL)
>  		goto nomem;
>  
>  	if (gfp_mask & __GFP_NOFAIL)
> @@ -2400,7 +2399,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
>  	switch (oom_status) {
>  	case OOM_SUCCESS:
>  		nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
> -		oomed = true;
>  		goto retry;
>  	case OOM_FAILED:
>  		goto force;
> -- 
> 2.21.0.593.g511ec345e18-goog
> 

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] memcg, oom: no oom-kill for __GFP_RETRY_MAYFAIL
  2019-04-29 12:22 ` Michal Hocko
@ 2019-04-29 14:37   ` Shakeel Butt
  2019-04-29 14:52     ` Michal Hocko
  0 siblings, 1 reply; 4+ messages in thread
From: Shakeel Butt @ 2019-04-29 14:37 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Johannes Weiner, Vladimir Davydov, Andrew Morton, Roman Gushchin,
	Linux MM, Cgroups, LKML

On Mon, Apr 29, 2019 at 5:22 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Sun 28-04-19 16:56:13, Shakeel Butt wrote:
> > The documentation of __GFP_RETRY_MAYFAIL clearly mentioned that the
> > OOM killer will not be triggered and indeed the page alloc does not
> > invoke OOM killer for such allocations. However we do trigger memcg
> > OOM killer for __GFP_RETRY_MAYFAIL. Fix that.
>
> An example of __GFP_RETRY_MAYFAIL memcg OOM report would be nice. I
> thought we haven't been using that flag for memcg allocations yet.
> But this is definitely good to have addressed.

Actually I am planning to use it for memcg allocations (specifically
fsnotify allocations).

>
> > Signed-off-by: Shakeel Butt <shakeelb@google.com>
>
> Acked-by: Michal Hocko <mhocko@suse.com>

Thanks.

>
> > ---
> >  mm/memcontrol.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 2713b45ec3f0..99eca724ed3b 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -2294,7 +2294,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> >       unsigned long nr_reclaimed;
> >       bool may_swap = true;
> >       bool drained = false;
> > -     bool oomed = false;
> >       enum oom_status oom_status;
> >
> >       if (mem_cgroup_is_root(memcg))
> > @@ -2381,7 +2380,7 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> >       if (nr_retries--)
> >               goto retry;
> >
> > -     if (gfp_mask & __GFP_RETRY_MAYFAIL && oomed)
> > +     if (gfp_mask & __GFP_RETRY_MAYFAIL)
> >               goto nomem;
> >
> >       if (gfp_mask & __GFP_NOFAIL)
> > @@ -2400,7 +2399,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> >       switch (oom_status) {
> >       case OOM_SUCCESS:
> >               nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
> > -             oomed = true;
> >               goto retry;
> >       case OOM_FAILED:
> >               goto force;
> > --
> > 2.21.0.593.g511ec345e18-goog
> >
>
> --
> Michal Hocko
> SUSE Labs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] memcg, oom: no oom-kill for __GFP_RETRY_MAYFAIL
  2019-04-29 14:37   ` Shakeel Butt
@ 2019-04-29 14:52     ` Michal Hocko
  0 siblings, 0 replies; 4+ messages in thread
From: Michal Hocko @ 2019-04-29 14:52 UTC (permalink / raw)
  To: Shakeel Butt
  Cc: Johannes Weiner, Vladimir Davydov, Andrew Morton, Roman Gushchin,
	Linux MM, Cgroups, LKML

On Mon 29-04-19 07:37:08, Shakeel Butt wrote:
> On Mon, Apr 29, 2019 at 5:22 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Sun 28-04-19 16:56:13, Shakeel Butt wrote:
> > > The documentation of __GFP_RETRY_MAYFAIL clearly mentioned that the
> > > OOM killer will not be triggered and indeed the page alloc does not
> > > invoke OOM killer for such allocations. However we do trigger memcg
> > > OOM killer for __GFP_RETRY_MAYFAIL. Fix that.
> >
> > An example of __GFP_RETRY_MAYFAIL memcg OOM report would be nice. I
> > thought we haven't been using that flag for memcg allocations yet.
> > But this is definitely good to have addressed.
> 
> Actually I am planning to use it for memcg allocations (specifically
> fsnotify allocations).

OK, then articulate it in the changelog please.

> > > Signed-off-by: Shakeel Butt <shakeelb@google.com>
> >
> > Acked-by: Michal Hocko <mhocko@suse.com>
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-04-29 14:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-28 23:56 [PATCH] memcg, oom: no oom-kill for __GFP_RETRY_MAYFAIL Shakeel Butt
2019-04-29 12:22 ` Michal Hocko
2019-04-29 14:37   ` Shakeel Butt
2019-04-29 14:52     ` Michal Hocko

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).