From: Vlastimil Babka <vbabka@suse.cz>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
Li Zefan <lizefan@huawei.com>, Michal Hocko <mhocko@kernel.org>,
Mel Gorman <mgorman@techsingularity.net>,
David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>, Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>
Subject: [RFC 6/6] mm, mempolicy: don't check cpuset seqlock where it doesn't matter
Date: Tue, 11 Apr 2017 16:06:09 +0200 [thread overview]
Message-ID: <20170411140609.3787-7-vbabka@suse.cz> (raw)
In-Reply-To: <20170411140609.3787-1-vbabka@suse.cz>
Two wrappers of __alloc_pages_nodemask() are checking task->mems_allowed_seq
themselves to retry allocation that has raced with a cpuset update. This has
been shown to be ineffective in preventing premature OOM's which can happen in
__alloc_pages_slowpath() long before it returns back to the wrappers to detect
the race at that level. Previous patches have made __alloc_pages_slowpath()
more robust, so we can now simply remove the seqlock checking in the wrappers
to prevent further wrong impression that it can actually help.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/mempolicy.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 72e5aeb1feeb..9a542b7a2189 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1900,12 +1900,9 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
struct mempolicy *pol;
struct page *page;
int preferred_nid;
- unsigned int cpuset_mems_cookie;
nodemask_t *nmask;
-retry_cpuset:
pol = get_vma_policy(vma, addr);
- cpuset_mems_cookie = read_mems_allowed_begin();
if (pol->mode == MPOL_INTERLEAVE) {
unsigned nid;
@@ -1947,8 +1944,6 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
page = __alloc_pages_nodemask(gfp, order, preferred_nid, nmask);
mpol_cond_put(pol);
out:
- if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
- goto retry_cpuset;
return page;
}
@@ -1966,23 +1961,15 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
* Allocate a page from the kernel page pool. When not in
* interrupt context and apply the current process NUMA policy.
* Returns NULL when no page can be allocated.
- *
- * Don't call cpuset_update_task_memory_state() unless
- * 1) it's ok to take cpuset_sem (can WAIT), and
- * 2) allocating for current task (not interrupt).
*/
struct page *alloc_pages_current(gfp_t gfp, unsigned order)
{
struct mempolicy *pol = &default_policy;
struct page *page;
- unsigned int cpuset_mems_cookie;
if (!in_interrupt() && !(gfp & __GFP_THISNODE))
pol = get_task_policy(current);
-retry_cpuset:
- cpuset_mems_cookie = read_mems_allowed_begin();
-
/*
* No reference counting needed for current->mempolicy
* nor system default_policy
@@ -1994,9 +1981,6 @@ struct page *alloc_pages_current(gfp_t gfp, unsigned order)
policy_node(gfp, pol, numa_node_id()),
policy_nodemask(gfp, pol));
- if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
- goto retry_cpuset;
-
return page;
}
EXPORT_SYMBOL(alloc_pages_current);
--
2.12.2
--
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: Vlastimil Babka <vbabka@suse.cz>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
Li Zefan <lizefan@huawei.com>, Michal Hocko <mhocko@kernel.org>,
Mel Gorman <mgorman@techsingularity.net>,
David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>, Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>
Subject: [RFC 6/6] mm, mempolicy: don't check cpuset seqlock where it doesn't matter
Date: Tue, 11 Apr 2017 16:06:09 +0200 [thread overview]
Message-ID: <20170411140609.3787-7-vbabka@suse.cz> (raw)
In-Reply-To: <20170411140609.3787-1-vbabka@suse.cz>
Two wrappers of __alloc_pages_nodemask() are checking task->mems_allowed_seq
themselves to retry allocation that has raced with a cpuset update. This has
been shown to be ineffective in preventing premature OOM's which can happen in
__alloc_pages_slowpath() long before it returns back to the wrappers to detect
the race at that level. Previous patches have made __alloc_pages_slowpath()
more robust, so we can now simply remove the seqlock checking in the wrappers
to prevent further wrong impression that it can actually help.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/mempolicy.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 72e5aeb1feeb..9a542b7a2189 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1900,12 +1900,9 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
struct mempolicy *pol;
struct page *page;
int preferred_nid;
- unsigned int cpuset_mems_cookie;
nodemask_t *nmask;
-retry_cpuset:
pol = get_vma_policy(vma, addr);
- cpuset_mems_cookie = read_mems_allowed_begin();
if (pol->mode == MPOL_INTERLEAVE) {
unsigned nid;
@@ -1947,8 +1944,6 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
page = __alloc_pages_nodemask(gfp, order, preferred_nid, nmask);
mpol_cond_put(pol);
out:
- if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
- goto retry_cpuset;
return page;
}
@@ -1966,23 +1961,15 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
* Allocate a page from the kernel page pool. When not in
* interrupt context and apply the current process NUMA policy.
* Returns NULL when no page can be allocated.
- *
- * Don't call cpuset_update_task_memory_state() unless
- * 1) it's ok to take cpuset_sem (can WAIT), and
- * 2) allocating for current task (not interrupt).
*/
struct page *alloc_pages_current(gfp_t gfp, unsigned order)
{
struct mempolicy *pol = &default_policy;
struct page *page;
- unsigned int cpuset_mems_cookie;
if (!in_interrupt() && !(gfp & __GFP_THISNODE))
pol = get_task_policy(current);
-retry_cpuset:
- cpuset_mems_cookie = read_mems_allowed_begin();
-
/*
* No reference counting needed for current->mempolicy
* nor system default_policy
@@ -1994,9 +1981,6 @@ struct page *alloc_pages_current(gfp_t gfp, unsigned order)
policy_node(gfp, pol, numa_node_id()),
policy_nodemask(gfp, pol));
- if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
- goto retry_cpuset;
-
return page;
}
EXPORT_SYMBOL(alloc_pages_current);
--
2.12.2
next prev parent reply other threads:[~2017-04-11 14:06 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 14:06 [RFC 0/6] cpuset/mempolicies related fixes and cleanups Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 17:24 ` Christoph Lameter
2017-04-11 17:24 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704111152170.25069-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-04-11 19:00 ` Vlastimil Babka
2017-04-11 19:00 ` Vlastimil Babka
2017-04-11 19:00 ` Vlastimil Babka
2017-04-12 21:25 ` Christoph Lameter
2017-04-12 21:25 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704121617040.28335-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-04-13 6:24 ` Vlastimil Babka
2017-04-13 6:24 ` Vlastimil Babka
2017-04-13 6:24 ` Vlastimil Babka
2017-04-14 20:37 ` Christoph Lameter
2017-04-14 20:37 ` Christoph Lameter
2017-04-26 8:07 ` Vlastimil Babka
2017-04-26 8:07 ` Vlastimil Babka
2017-04-30 21:33 ` Christoph Lameter
2017-04-30 21:33 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704301628460.21533-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-17 9:20 ` Michal Hocko
2017-05-17 9:20 ` Michal Hocko
2017-05-17 9:20 ` Michal Hocko
[not found] ` <20170517092042.GH18247-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-17 13:56 ` Christoph Lameter
2017-05-17 13:56 ` Christoph Lameter
2017-05-17 13:56 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705170855430.7925-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-17 14:05 ` Michal Hocko
2017-05-17 14:05 ` Michal Hocko
2017-05-17 14:05 ` Michal Hocko
2017-05-17 14:48 ` Christoph Lameter
2017-05-17 14:48 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705170943090.8714-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-17 14:56 ` Michal Hocko
2017-05-17 14:56 ` Michal Hocko
2017-05-17 14:56 ` Michal Hocko
2017-05-17 15:25 ` Christoph Lameter
2017-05-17 15:25 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705171021570.9487-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-18 9:08 ` Michal Hocko
2017-05-18 9:08 ` Michal Hocko
2017-05-18 9:08 ` Michal Hocko
[not found] ` <20170518090846.GD25462-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-18 16:57 ` Christoph Lameter
2017-05-18 16:57 ` Christoph Lameter
2017-05-18 16:57 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1705181154450.27641-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-05-18 17:24 ` Michal Hocko
2017-05-18 17:24 ` Michal Hocko
2017-05-18 17:24 ` Michal Hocko
[not found] ` <20170518172424.GB30148-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-18 19:07 ` Christoph Lameter
2017-05-18 19:07 ` Christoph Lameter
2017-05-18 19:07 ` Christoph Lameter
2017-05-19 7:37 ` Michal Hocko
2017-05-19 7:37 ` Michal Hocko
2017-05-17 15:27 ` Christoph Lameter
2017-05-17 15:27 ` Christoph Lameter
2017-05-18 10:03 ` Vlastimil Babka
2017-05-18 10:03 ` Vlastimil Babka
2017-05-18 17:07 ` Christoph Lameter
2017-05-18 17:07 ` Christoph Lameter
2017-05-19 11:27 ` Vlastimil Babka
2017-05-19 11:27 ` Vlastimil Babka
2017-04-13 5:42 ` Anshuman Khandual
2017-04-13 5:42 ` Anshuman Khandual
2017-04-13 6:06 ` Vlastimil Babka
2017-04-13 6:06 ` Vlastimil Babka
2017-04-13 6:07 ` Vlastimil Babka
2017-04-13 6:07 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask() Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 17:32 ` Christoph Lameter
2017-04-11 17:32 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1704111227080.25069-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2017-04-11 19:03 ` Vlastimil Babka
2017-04-11 19:03 ` Vlastimil Babka
2017-04-11 19:03 ` Vlastimil Babka
2017-04-12 8:49 ` Vlastimil Babka
2017-04-12 8:49 ` Vlastimil Babka
[not found] ` <97045760-77eb-c892-9bcb-daad10a1d91d-AlSwsSmVLrQ@public.gmane.org>
2017-04-12 21:16 ` Christoph Lameter
2017-04-12 21:16 ` Christoph Lameter
2017-04-12 21:16 ` Christoph Lameter
2017-04-12 21:18 ` Vlastimil Babka
2017-04-12 21:18 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 4/6] mm, mempolicy: simplify rebinding mempolicies when updating cpusets Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 5/6] mm, cpuset: always use seqlock when changing task's nodemask Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka
2017-04-12 8:10 ` Hillf Danton
2017-04-12 8:10 ` Hillf Danton
2017-04-12 8:18 ` Vlastimil Babka
2017-04-12 8:18 ` Vlastimil Babka
2017-04-12 8:18 ` Vlastimil Babka
2017-04-11 14:06 ` Vlastimil Babka [this message]
2017-04-11 14:06 ` [RFC 6/6] mm, mempolicy: don't check cpuset seqlock where it doesn't matter Vlastimil Babka
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=20170411140609.3787-7-vbabka@suse.cz \
--to=vbabka@suse.cz \
--cc=aarcange@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=cl@linux.com \
--cc=hughd@google.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=rientjes@google.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: 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.