All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	azurIt <azurit@pobox.sk>,
	linux-mm@kvack.org, cgroups@vger.kernel.org, x86@kernel.org,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 5/6] mm: memcg: enable memcg OOM killer only for user faults
Date: Fri, 26 Jul 2013 14:54:07 -0400	[thread overview]
Message-ID: <20130726185407.GC17975@cmpxchg.org> (raw)
In-Reply-To: <20130726141642.GG17761@dhcp22.suse.cz>

On Fri, Jul 26, 2013 at 04:16:42PM +0200, Michal Hocko wrote:
> On Thu 25-07-13 18:25:37, Johannes Weiner wrote:
> > System calls and kernel faults (uaccess, gup) can handle an out of
> > memory situation gracefully and just return -ENOMEM.
> > 
> > Enable the memcg OOM killer only for user faults, where it's really
> > the only option available.
> > 
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> 
> It looks OK to me, but I have few comments bellow. Nothing really huge
> but I do not like mem_cgroup_xchg_may_oom for !MEMCG.

:-)

> > ---
> >  include/linux/memcontrol.h | 23 +++++++++++++++++++++++
> >  include/linux/sched.h      |  3 +++
> >  mm/filemap.c               | 11 ++++++++++-
> >  mm/memcontrol.c            |  2 +-
> >  mm/memory.c                | 40 ++++++++++++++++++++++++++++++----------
> >  5 files changed, 67 insertions(+), 12 deletions(-)
> > 
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index 7b4d9d7..9bb5eeb 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -125,6 +125,24 @@ extern void mem_cgroup_print_oom_info(struct mem_cgroup *memcg,
> >  extern void mem_cgroup_replace_page_cache(struct page *oldpage,
> >  					struct page *newpage);
> >  
> > +/**
> > + * mem_cgroup_xchg_may_oom - toggle the memcg OOM killer for a task
> > + * @p: task
> 
> Is this ever safe to call on !current? If not then I wouldn't allow to
> give p as a parameter.

Makes sense, I removed the parameter.

> > @@ -1634,10 +1639,14 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> >  		 * We found the page, so try async readahead before
> >  		 * waiting for the lock.
> >  		 */
> > +		may_oom = mem_cgroup_xchg_may_oom(current, 0);
> 
> s/0/false/
> 
> below ditto

Oops, updated both sites.

> >  		do_async_mmap_readahead(vma, ra, file, page, offset);
> > +		mem_cgroup_xchg_may_oom(current, may_oom);
> >  	} else if (!page) {
> >  		/* No page in the page cache at all */
> > +		may_oom = mem_cgroup_xchg_may_oom(current, 0);
> >  		do_sync_mmap_readahead(vma, ra, file, offset);
> > +		mem_cgroup_xchg_may_oom(current, may_oom);
> >  		count_vm_event(PGMAJFAULT);
> >  		mem_cgroup_count_vm_event(vma->vm_mm, PGMAJFAULT);
> >  		ret = VM_FAULT_MAJOR;
> [...]
> > diff --git a/mm/memory.c b/mm/memory.c
> > index f2ab2a8..5ea7b47 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> [...]
> > @@ -3851,6 +3843,34 @@ retry:
> >  	return handle_pte_fault(mm, vma, address, pte, pmd, flags);
> >  }
> >  
> > +int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> > +		    unsigned long address, unsigned int flags)
> > +{
> > +	int ret;
> > +
> > +	__set_current_state(TASK_RUNNING);
> > +
> > +	count_vm_event(PGFAULT);
> > +	mem_cgroup_count_vm_event(mm, PGFAULT);
> > +
> > +	/* do counter updates before entering really critical section. */
> > +	check_sync_rss_stat(current);
> > +
> > +	/*
> > +	 * Enable the memcg OOM handling for faults triggered in user
> > +	 * space.  Kernel faults are handled more gracefully.
> > +	 */
> > +	if (flags & FAULT_FLAG_USER)
> > +		WARN_ON(mem_cgroup_xchg_may_oom(current, true) == true);
> > +
> > +	ret = __handle_mm_fault(mm, vma, address, flags);
> > +
> > +	if (flags & FAULT_FLAG_USER)
> > +		WARN_ON(mem_cgroup_xchg_may_oom(current, false) == false);
> 
> Ohh, I see why you used !new in mem_cgroup_xchg_may_oom for !MEMCG case
> above. This could be fixed easily if you add mem_cgroup_{enable,disable}_oom
> which would be empty for !MEMCG.

You're right, it's much cleaner this way.  I added the enable/disable
functions, which has the advantage that the memcg-specific WARN_ON is
also not in generic code but encapsulated nicely.

Thanks for your feedback!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	azurIt <azurit@pobox.sk>,
	linux-mm@kvack.org, cgroups@vger.kernel.org, x86@kernel.org,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 5/6] mm: memcg: enable memcg OOM killer only for user faults
Date: Fri, 26 Jul 2013 14:54:07 -0400	[thread overview]
Message-ID: <20130726185407.GC17975@cmpxchg.org> (raw)
Message-ID: <20130726185407.aD1E_wRi1KPu7RqJi9Ou9ZaOlHU7d8neIuVkflDfnzc@z> (raw)
In-Reply-To: <20130726141642.GG17761@dhcp22.suse.cz>

On Fri, Jul 26, 2013 at 04:16:42PM +0200, Michal Hocko wrote:
> On Thu 25-07-13 18:25:37, Johannes Weiner wrote:
> > System calls and kernel faults (uaccess, gup) can handle an out of
> > memory situation gracefully and just return -ENOMEM.
> > 
> > Enable the memcg OOM killer only for user faults, where it's really
> > the only option available.
> > 
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> 
> It looks OK to me, but I have few comments bellow. Nothing really huge
> but I do not like mem_cgroup_xchg_may_oom for !MEMCG.

:-)

> > ---
> >  include/linux/memcontrol.h | 23 +++++++++++++++++++++++
> >  include/linux/sched.h      |  3 +++
> >  mm/filemap.c               | 11 ++++++++++-
> >  mm/memcontrol.c            |  2 +-
> >  mm/memory.c                | 40 ++++++++++++++++++++++++++++++----------
> >  5 files changed, 67 insertions(+), 12 deletions(-)
> > 
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index 7b4d9d7..9bb5eeb 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -125,6 +125,24 @@ extern void mem_cgroup_print_oom_info(struct mem_cgroup *memcg,
> >  extern void mem_cgroup_replace_page_cache(struct page *oldpage,
> >  					struct page *newpage);
> >  
> > +/**
> > + * mem_cgroup_xchg_may_oom - toggle the memcg OOM killer for a task
> > + * @p: task
> 
> Is this ever safe to call on !current? If not then I wouldn't allow to
> give p as a parameter.

Makes sense, I removed the parameter.

> > @@ -1634,10 +1639,14 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> >  		 * We found the page, so try async readahead before
> >  		 * waiting for the lock.
> >  		 */
> > +		may_oom = mem_cgroup_xchg_may_oom(current, 0);
> 
> s/0/false/
> 
> below ditto

Oops, updated both sites.

> >  		do_async_mmap_readahead(vma, ra, file, page, offset);
> > +		mem_cgroup_xchg_may_oom(current, may_oom);
> >  	} else if (!page) {
> >  		/* No page in the page cache at all */
> > +		may_oom = mem_cgroup_xchg_may_oom(current, 0);
> >  		do_sync_mmap_readahead(vma, ra, file, offset);
> > +		mem_cgroup_xchg_may_oom(current, may_oom);
> >  		count_vm_event(PGMAJFAULT);
> >  		mem_cgroup_count_vm_event(vma->vm_mm, PGMAJFAULT);
> >  		ret = VM_FAULT_MAJOR;
> [...]
> > diff --git a/mm/memory.c b/mm/memory.c
> > index f2ab2a8..5ea7b47 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> [...]
> > @@ -3851,6 +3843,34 @@ retry:
> >  	return handle_pte_fault(mm, vma, address, pte, pmd, flags);
> >  }
> >  
> > +int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> > +		    unsigned long address, unsigned int flags)
> > +{
> > +	int ret;
> > +
> > +	__set_current_state(TASK_RUNNING);
> > +
> > +	count_vm_event(PGFAULT);
> > +	mem_cgroup_count_vm_event(mm, PGFAULT);
> > +
> > +	/* do counter updates before entering really critical section. */
> > +	check_sync_rss_stat(current);
> > +
> > +	/*
> > +	 * Enable the memcg OOM handling for faults triggered in user
> > +	 * space.  Kernel faults are handled more gracefully.
> > +	 */
> > +	if (flags & FAULT_FLAG_USER)
> > +		WARN_ON(mem_cgroup_xchg_may_oom(current, true) == true);
> > +
> > +	ret = __handle_mm_fault(mm, vma, address, flags);
> > +
> > +	if (flags & FAULT_FLAG_USER)
> > +		WARN_ON(mem_cgroup_xchg_may_oom(current, false) == false);
> 
> Ohh, I see why you used !new in mem_cgroup_xchg_may_oom for !MEMCG case
> above. This could be fixed easily if you add mem_cgroup_{enable,disable}_oom
> which would be empty for !MEMCG.

You're right, it's much cleaner this way.  I added the enable/disable
functions, which has the advantage that the memcg-specific WARN_ON is
also not in generic code but encapsulated nicely.

Thanks for your feedback!

  reply	other threads:[~2013-07-26 18:54 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 22:25 [patch 0/6] improve memcg oom killer robustness Johannes Weiner
2013-07-25 22:25 ` Johannes Weiner
2013-07-25 22:25 ` [patch 1/6] arch: mm: remove obsolete init OOM protection Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
2013-07-26 13:00   ` Michal Hocko
2013-07-26 13:00     ` Michal Hocko
2013-07-29 18:55   ` KOSAKI Motohiro
2013-07-29 18:55     ` KOSAKI Motohiro
2013-07-25 22:25 ` [patch 2/6] arch: mm: do not invoke OOM killer on kernel fault OOM Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
2013-07-26 13:07   ` Michal Hocko
2013-07-26 13:07     ` Michal Hocko
     [not found]   ` <1374791138-15665-3-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-29 18:58     ` KOSAKI Motohiro
2013-07-29 18:58       ` KOSAKI Motohiro
2013-07-29 18:58       ` KOSAKI Motohiro
2013-08-01 21:59       ` Johannes Weiner
2013-08-01 21:59         ` Johannes Weiner
2013-07-25 22:25 ` [patch 3/6] arch: mm: pass userspace fault flag to generic fault handler Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
     [not found]   ` <1374791138-15665-4-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-26 13:19     ` Michal Hocko
2013-07-26 13:19       ` Michal Hocko
2013-07-26 13:19       ` Michal Hocko
2013-07-26 18:45       ` Johannes Weiner
2013-07-26 18:45         ` Johannes Weiner
2013-07-25 22:25 ` [patch 4/6] x86: finish user fault error path with fatal signal Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
2013-07-26 13:52   ` Michal Hocko
2013-07-26 13:52     ` Michal Hocko
2013-07-26 18:46     ` Johannes Weiner
2013-07-26 18:46       ` Johannes Weiner
2013-07-29 12:45       ` Michal Hocko
2013-07-29 12:45         ` Michal Hocko
2013-07-29 19:01   ` KOSAKI Motohiro
2013-07-29 19:01     ` KOSAKI Motohiro
2013-07-25 22:25 ` [patch 5/6] mm: memcg: enable memcg OOM killer only for user faults Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
     [not found]   ` <1374791138-15665-6-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-26 14:16     ` Michal Hocko
2013-07-26 14:16       ` Michal Hocko
2013-07-26 14:16       ` Michal Hocko
2013-07-26 18:54       ` Johannes Weiner [this message]
2013-07-26 18:54         ` Johannes Weiner
2013-07-29 19:18   ` KOSAKI Motohiro
2013-07-29 19:18     ` KOSAKI Motohiro
     [not found]     ` <51F6C00C.5050702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-29 19:44       ` Johannes Weiner
2013-07-29 19:44         ` Johannes Weiner
2013-07-29 19:44         ` Johannes Weiner
2013-07-29 19:47         ` KOSAKI Motohiro
2013-07-29 19:47           ` KOSAKI Motohiro
2013-07-25 22:25 ` [patch 6/6] mm: memcg: do not trap chargers with full callstack on OOM Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
     [not found]   ` <1374791138-15665-7-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-26 14:43     ` Michal Hocko
2013-07-26 14:43       ` Michal Hocko
2013-07-26 14:43       ` Michal Hocko
2013-07-26 21:28       ` Johannes Weiner
2013-07-26 21:28         ` Johannes Weiner
2013-07-29 14:12         ` Michal Hocko
2013-07-29 14:12           ` Michal Hocko
     [not found]           ` <20130729141250.GF4678-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-29 14:55             ` Johannes Weiner
2013-07-29 14:55               ` Johannes Weiner
2013-07-29 14:55               ` Johannes Weiner
     [not found]               ` <20130729145529.GW715-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-29 15:52                 ` Michal Hocko
2013-07-29 15:52                   ` Michal Hocko
2013-07-29 15:52                   ` Michal Hocko
     [not found]         ` <20130726212808.GD17975-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-30 14:09           ` Michal Hocko
2013-07-30 14:09             ` Michal Hocko
2013-07-30 14:09             ` Michal Hocko
     [not found]             ` <20130730140913.GC15847-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-30 14:32               ` Johannes Weiner
2013-07-30 14:32                 ` Johannes Weiner
2013-07-30 14:32                 ` Johannes Weiner
     [not found]                 ` <20130730143228.GD715-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-30 14:56                   ` Michal Hocko
2013-07-30 14:56                     ` Michal Hocko
2013-07-30 14:56                     ` Michal Hocko
2013-07-25 22:31 ` [patch 3.2] memcg OOM robustness (x86 only) Johannes Weiner
2013-07-25 22:31   ` Johannes Weiner
2013-08-03  8:38   ` azurIt
2013-08-03  8:38     ` azurIt
2013-08-03 16:30     ` Johannes Weiner
2013-08-03 16:30       ` Johannes Weiner

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=20130726185407.GC17975@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=azurit@pobox.sk \
    --cc=cgroups@vger.kernel.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=rientjes@google.com \
    --cc=x86@kernel.org \
    /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
Be 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.