* Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration
From: Marcelo Tosatti @ 2017-05-19 14:34 UTC (permalink / raw)
To: Christoph Lameter
Cc: Luiz Capitulino, linux-kernel, linux-mm, Rik van Riel,
Linux RT Users, cmetcalf
In-Reply-To: <alpine.DEB.2.20.1705160825480.32761@east.gentwo.org>
Hi Christoph,
On Tue, May 16, 2017 at 08:37:11AM -0500, Christoph Lameter wrote:
> On Mon, 15 May 2017, Marcelo Tosatti wrote:
>
> > > NOHZ already does that. I wanted to know what your problem is that you
> > > see. The latency issue has already been solved as far as I can tell .
> > > Please tell me why the existing solutions are not sufficient for you.
> >
> > We don't want vmstat_worker to execute on a given CPU, even if the local
> > CPU updates vm-statistics.
>
> Instead of responding you repeat describing what you want.
>
> > Because:
> >
> > vmstat_worker increases latency of the application
> > (i can measure it if you want on a given CPU,
> > how many ns's the following takes:
>
> That still is no use case.
Use-case: realtime application on an isolated core which for some reason
updates vmstatistics.
> Just a measurement of vmstat_worker. Pointless.
Shouldnt the focus be on general scenarios rather than particular
usecases, so that the solution covers a wider range of usecases?
The situation as i see is as follows:
Your point of view is: an "isolated CPU" with a set of applications
cannot update vm statistics, otherwise they pay the vmstat_update cost:
kworker/5:1-245 [005] ....1.. 673.454295: workqueue_execute_start: work struct ffffa0cf6e493e20: function vmstat_update
kworker/5:1-245 [005] ....1.. 673.454305: workqueue_execute_end: work struct ffffa0cf6e493e20
Thats 10us for example.
So if want to customize a realtime setup whose code updates vmstatistic,
you are dead. You have to avoid any systemcall which possibly updates
vmstatistics (now and in the future kernel versions).
> If you move the latency from the vmstat worker into the code thats
> updating the counters then you will require increased use of atomics
> which will increase contention which in turn will significantly
> increase the overall latency.
The point is that these vmstat updates are rare. From
http://www.7-cpu.com/cpu/Haswell.html:
RAM Latency = 36 cycles + 57 ns (3.4 GHz i7-4770)
RAM Latency = 62 cycles + 100 ns (3.6 GHz E5-2699 dual)
Lets round to 100ns = 0.1us.
You need 100 vmstat updates (all misses to RAM, the worst possible case)
to have equivalent amount of time of the batching version.
With more than 100 vmstat updates, then the batching is more efficient
(as in total amount of time to transfer to global counters).
But thats not the point. The point is the 10us interruption
to execution of the realtime app (which can either mean
your current deadline requirements are not met, or that
another application with lowest latency requirement can't
be used).
So i'd rather spend more time updating the aggregate of vmstatistics
(with the local->global transfer taking a small amount of time,
therefore not interrupting the realtime application for a long period),
than to batch the updates (which increases overall performance beyond
a certain number of updates, but which is _ONE_ large interruption).
So lets assume i go and count the vmstat updates on the DPDK case
(or any other realtime app), batching is more efficient
for that case.
Still, the one-time interruption of batching is worse than less
efficient one bean at a time vmstatistics accounting.
No?
Also, you could reply that: "oh, there are no vmstat updates
in fact in this setup, but the logic of disabling vmstat_update
is broken". Lets assume thats the case.
Even if its fixed (vmstat_update properly shut down) the proposed patch
deals with both cases: no vmstat updates on isolated cpus, and vmstat
updates on isolated cpus.
So why are you against integrating this simple, isolated patch which
does not affect how current logic works?
--
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>
^ permalink raw reply
* Re: [PATCH] mm/oom_kill: count global and memory cgroup oom kills
From: Michal Hocko @ 2017-05-19 14:32 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: linux-mm, Andrew Morton, Tejun Heo, cgroups, linux-kernel,
Vlastimil Babka, Vladimir Davydov, Johannes Weiner
In-Reply-To: <149520375057.74196.2843113275800730971.stgit@buzz>
[CC Vladimir and Johannes as this involves memcg]
i will get to this early next week but from a quick look it seems
acceptable.
On Fri 19-05-17 17:22:30, Konstantin Khlebnikov wrote:
> Show count of global oom killer invocations in /proc/vmstat and
> count of oom kills inside memory cgroup in knob "memory.events"
> (in memory.oom_control for v1 cgroup).
>
> Also describe difference between "oom" and "oom_kill" in memory
> cgroup documentation. Currently oom in memory cgroup kills tasks
> iff shortage has happened inside page fault.
>
> These counters helps in monitoring oom kills - for now
> the only way is grepping for magic words in kernel log.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> ---
> Documentation/cgroup-v2.txt | 12 +++++++++++-
> include/linux/memcontrol.h | 1 +
> include/linux/vm_event_item.h | 1 +
> mm/memcontrol.c | 2 ++
> mm/oom_kill.c | 6 ++++++
> mm/vmstat.c | 1 +
> 6 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index dc5e2dcdbef4..a742008d76aa 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -830,9 +830,19 @@ PAGE_SIZE multiple when read back.
>
> oom
>
> + The number of time the cgroup's memory usage was
> + reached the limit and allocation was about to fail.
> + Result could be oom kill, -ENOMEM from any syscall or
> + completely ignored in cases like disk readahead.
> + For now oom in memory cgroup kills tasks iff shortage
> + has happened inside page fault.
> +
> + oom_kill
> +
> The number of times the OOM killer has been invoked in
> the cgroup. This may not exactly match the number of
> - processes killed but should generally be close.
> + processes killed but should generally be close: each
> + invocation could kill several processes at once.
>
> memory.stat
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 899949bbb2f9..2cdcebb78b58 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -55,6 +55,7 @@ enum memcg_event_item {
> MEMCG_HIGH,
> MEMCG_MAX,
> MEMCG_OOM,
> + MEMCG_OOM_KILL,
> MEMCG_NR_EVENTS,
> };
>
> diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
> index d84ae90ccd5c..1707e0a7d943 100644
> --- a/include/linux/vm_event_item.h
> +++ b/include/linux/vm_event_item.h
> @@ -41,6 +41,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
> KSWAPD_LOW_WMARK_HIT_QUICKLY, KSWAPD_HIGH_WMARK_HIT_QUICKLY,
> PAGEOUTRUN, PGROTATED,
> DROP_PAGECACHE, DROP_SLAB,
> + OOM_KILL,
> #ifdef CONFIG_NUMA_BALANCING
> NUMA_PTE_UPDATES,
> NUMA_HUGE_PTE_UPDATES,
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 94172089f52f..416024837b81 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3574,6 +3574,7 @@ static int mem_cgroup_oom_control_read(struct seq_file *sf, void *v)
>
> seq_printf(sf, "oom_kill_disable %d\n", memcg->oom_kill_disable);
> seq_printf(sf, "under_oom %d\n", (bool)memcg->under_oom);
> + seq_printf(sf, "oom_kill %lu\n", memcg_sum_events(memcg, MEMCG_OOM_KILL));
> return 0;
> }
>
> @@ -5165,6 +5166,7 @@ static int memory_events_show(struct seq_file *m, void *v)
> seq_printf(m, "high %lu\n", memcg_sum_events(memcg, MEMCG_HIGH));
> seq_printf(m, "max %lu\n", memcg_sum_events(memcg, MEMCG_MAX));
> seq_printf(m, "oom %lu\n", memcg_sum_events(memcg, MEMCG_OOM));
> + seq_printf(m, "oom_kill %lu\n", memcg_sum_events(memcg, MEMCG_OOM_KILL));
>
> return 0;
> }
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 04c9143a8625..c50bff3c3409 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -873,6 +873,12 @@ static void oom_kill_process(struct oom_control *oc, const char *message)
> victim = p;
> }
>
> + /* Raise event before sending signal: reaper must see this */
> + if (!is_memcg_oom(oc))
> + count_vm_event(OOM_KILL);
> + else
> + mem_cgroup_event(oc->memcg, MEMCG_OOM_KILL);
> +
> /* Get a reference to safely compare mm after task_unlock(victim) */
> mm = victim->mm;
> mmgrab(mm);
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 76f73670200a..fe80b81a86e0 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1018,6 +1018,7 @@ const char * const vmstat_text[] = {
>
> "drop_pagecache",
> "drop_slab",
> + "oom_kill",
>
> #ifdef CONFIG_NUMA_BALANCING
> "numa_pte_updates",
>
> --
> 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>
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply
* [PATCH] mm/oom_kill: count global and memory cgroup oom kills
From: Konstantin Khlebnikov @ 2017-05-19 14:22 UTC (permalink / raw)
To: linux-mm, Andrew Morton
Cc: Tejun Heo, cgroups, linux-kernel, Vlastimil Babka, Michal Hocko
Show count of global oom killer invocations in /proc/vmstat and
count of oom kills inside memory cgroup in knob "memory.events"
(in memory.oom_control for v1 cgroup).
Also describe difference between "oom" and "oom_kill" in memory
cgroup documentation. Currently oom in memory cgroup kills tasks
iff shortage has happened inside page fault.
These counters helps in monitoring oom kills - for now
the only way is grepping for magic words in kernel log.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
Documentation/cgroup-v2.txt | 12 +++++++++++-
include/linux/memcontrol.h | 1 +
include/linux/vm_event_item.h | 1 +
mm/memcontrol.c | 2 ++
mm/oom_kill.c | 6 ++++++
mm/vmstat.c | 1 +
6 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index dc5e2dcdbef4..a742008d76aa 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -830,9 +830,19 @@ PAGE_SIZE multiple when read back.
oom
+ The number of time the cgroup's memory usage was
+ reached the limit and allocation was about to fail.
+ Result could be oom kill, -ENOMEM from any syscall or
+ completely ignored in cases like disk readahead.
+ For now oom in memory cgroup kills tasks iff shortage
+ has happened inside page fault.
+
+ oom_kill
+
The number of times the OOM killer has been invoked in
the cgroup. This may not exactly match the number of
- processes killed but should generally be close.
+ processes killed but should generally be close: each
+ invocation could kill several processes at once.
memory.stat
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 899949bbb2f9..2cdcebb78b58 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -55,6 +55,7 @@ enum memcg_event_item {
MEMCG_HIGH,
MEMCG_MAX,
MEMCG_OOM,
+ MEMCG_OOM_KILL,
MEMCG_NR_EVENTS,
};
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index d84ae90ccd5c..1707e0a7d943 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -41,6 +41,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
KSWAPD_LOW_WMARK_HIT_QUICKLY, KSWAPD_HIGH_WMARK_HIT_QUICKLY,
PAGEOUTRUN, PGROTATED,
DROP_PAGECACHE, DROP_SLAB,
+ OOM_KILL,
#ifdef CONFIG_NUMA_BALANCING
NUMA_PTE_UPDATES,
NUMA_HUGE_PTE_UPDATES,
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 94172089f52f..416024837b81 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3574,6 +3574,7 @@ static int mem_cgroup_oom_control_read(struct seq_file *sf, void *v)
seq_printf(sf, "oom_kill_disable %d\n", memcg->oom_kill_disable);
seq_printf(sf, "under_oom %d\n", (bool)memcg->under_oom);
+ seq_printf(sf, "oom_kill %lu\n", memcg_sum_events(memcg, MEMCG_OOM_KILL));
return 0;
}
@@ -5165,6 +5166,7 @@ static int memory_events_show(struct seq_file *m, void *v)
seq_printf(m, "high %lu\n", memcg_sum_events(memcg, MEMCG_HIGH));
seq_printf(m, "max %lu\n", memcg_sum_events(memcg, MEMCG_MAX));
seq_printf(m, "oom %lu\n", memcg_sum_events(memcg, MEMCG_OOM));
+ seq_printf(m, "oom_kill %lu\n", memcg_sum_events(memcg, MEMCG_OOM_KILL));
return 0;
}
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 04c9143a8625..c50bff3c3409 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -873,6 +873,12 @@ static void oom_kill_process(struct oom_control *oc, const char *message)
victim = p;
}
+ /* Raise event before sending signal: reaper must see this */
+ if (!is_memcg_oom(oc))
+ count_vm_event(OOM_KILL);
+ else
+ mem_cgroup_event(oc->memcg, MEMCG_OOM_KILL);
+
/* Get a reference to safely compare mm after task_unlock(victim) */
mm = victim->mm;
mmgrab(mm);
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 76f73670200a..fe80b81a86e0 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1018,6 +1018,7 @@ const char * const vmstat_text[] = {
"drop_pagecache",
"drop_slab",
+ "oom_kill",
#ifdef CONFIG_NUMA_BALANCING
"numa_pte_updates",
--
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>
^ permalink raw reply related
* Re: [PATCH v5 11/11] mm: memory_hotplug: memory hotremove supports thp migration
From: Anshuman Khandual @ 2017-05-19 13:56 UTC (permalink / raw)
To: Zi Yan, n-horiguchi, kirill.shutemov, linux-kernel, linux-mm
Cc: akpm, minchan, vbabka, mgorman, mhocko, khandual, zi.yan,
dnellans
In-Reply-To: <20170420204752.79703-12-zi.yan@sent.com>
On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>
> This patch enables thp migration for memory hotremove.
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> ---
> ChangeLog v1->v2:
> - base code switched from alloc_migrate_target to new_node_page()
> ---
> include/linux/huge_mm.h | 8 ++++++++
> mm/memory_hotplug.c | 17 ++++++++++++++---
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 6f44a2352597..92c2161704c3 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -189,6 +189,13 @@ static inline int hpage_nr_pages(struct page *page)
> return 1;
> }
>
> +static inline int hpage_order(struct page *page)
> +{
> + if (unlikely(PageTransHuge(page)))
> + return HPAGE_PMD_ORDER;
> + return 0;
> +}
> +
This function seems to be redundant.
> struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
> pmd_t *pmd, int flags);
> struct page *follow_devmap_pud(struct vm_area_struct *vma, unsigned long addr,
> @@ -233,6 +240,7 @@ static inline bool thp_migration_supported(void)
> #define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
>
> #define hpage_nr_pages(x) 1
> +#define hpage_order(x) 0
>
> #define transparent_hugepage_enabled(__vma) 0
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 257166ebdff0..ecae0852994f 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1574,6 +1574,7 @@ static struct page *new_node_page(struct page *page, unsigned long private,
> int nid = page_to_nid(page);
> nodemask_t nmask = node_states[N_MEMORY];
> struct page *new_page = NULL;
> + unsigned int order = 0;
>
> /*
> * TODO: allocate a destination hugepage from a nearest neighbor node,
> @@ -1584,6 +1585,11 @@ static struct page *new_node_page(struct page *page, unsigned long private,
> return alloc_huge_page_node(page_hstate(compound_head(page)),
> next_node_in(nid, nmask));
>
> + if (thp_migration_supported() && PageTransHuge(page)) {
> + order = hpage_order(page);
We have already tested the page as THP, we can just use HPAGE_PMD_ORDER.
> + gfp_mask |= GFP_TRANSHUGE;
> + }
> +
> node_clear(nid, nmask);
>
> if (PageHighMem(page)
> @@ -1591,12 +1597,15 @@ static struct page *new_node_page(struct page *page, unsigned long private,
> gfp_mask |= __GFP_HIGHMEM;
>
> if (!nodes_empty(nmask))
> - new_page = __alloc_pages_nodemask(gfp_mask, 0,
> + new_page = __alloc_pages_nodemask(gfp_mask, order,
> node_zonelist(nid, gfp_mask), &nmask);
> if (!new_page)
> - new_page = __alloc_pages(gfp_mask, 0,
> + new_page = __alloc_pages(gfp_mask, order,
> node_zonelist(nid, gfp_mask));
>
> + if (new_page && order == hpage_order(page))
> + prep_transhuge_page(new_page);
> +
new_page has been allocated with 'order' already. I guess just checking
for PageTransHuge(page) on the old THP 'page' should be sufficient as
that has not been changed in any way.
--
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>
^ permalink raw reply
* Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF
From: Michal Hocko @ 2017-05-19 13:22 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: akpm, hannes, guro, vdavydov.dev, linux-mm, linux-kernel
In-Reply-To: <201705192202.EDD30719.OSLJHFMOFtFVOQ@I-love.SAKURA.ne.jp>
On Fri 19-05-17 22:02:44, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > Any allocation failure during the #PF path will return with VM_FAULT_OOM
> > which in turn results in pagefault_out_of_memory. This can happen for
> > 2 different reasons. a) Memcg is out of memory and we rely on
> > mem_cgroup_oom_synchronize to perform the memcg OOM handling or b)
> > normal allocation fails.
> >
> > The later is quite problematic because allocation paths already trigger
> > out_of_memory and the page allocator tries really hard to not fail
>
> We made many memory allocation requests from page fault path (e.g. XFS)
> __GFP_FS some time ago, didn't we? But if I recall correctly (I couldn't
> find the message), there are some allocation requests from page fault path
> which cannot use __GFP_FS. Then, not all allocation requests can call
> oom_kill_process() and reaching pagefault_out_of_memory() will be
> inevitable.
Even if such an allocation fail without the OOM killer then we simply
retry the PF and will do that the same way how we keep retrying the
allocation inside the page allocator. So how is this any different?
> > allocations. Anyway, if the OOM killer has been already invoked there
> > is no reason to invoke it again from the #PF path. Especially when the
> > OOM condition might be gone by that time and we have no way to find out
> > other than allocate.
> >
> > Moreover if the allocation failed and the OOM killer hasn't been
> > invoked then we are unlikely to do the right thing from the #PF context
> > because we have already lost the allocation context and restictions and
> > therefore might oom kill a task from a different NUMA domain.
>
> If we carry a flag via task_struct that indicates whether it is an memory
> allocation request from page fault and allocation failure is not acceptable,
> we can call out_of_memory() from page allocator path.
I do not understand
> > - if (!mutex_trylock(&oom_lock))
> > + if (fatal_signal_pending)
>
> fatal_signal_pending(current)
right, fixed
> By the way, can page fault occur after reaching do_exit()? When a thread
> reached do_exit(), fatal_signal_pending(current) becomes false, doesn't it?
yes fatal_signal_pending will be false at the time and I believe we can
perform a page fault past that moment and go via allocation path which would
trigger the OOM or give this task access to reserves but it is more
likely that the oom reaper will push to kill another task by that time
if the situation didn't get resolved. Or did I miss your concern?
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply
* Re: [PATCH v1] mm: drop NULL return check of pte_offset_map_lock()
From: Vlastimil Babka @ 2017-05-19 13:15 UTC (permalink / raw)
To: Naoya Horiguchi, linux-mm
Cc: Mel Gorman, Johannes Weiner, Andrea Arcangeli, Rik van Riel,
Andrew Morton, linux-kernel
In-Reply-To: <1495089737-1292-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On 05/18/2017 08:42 AM, Naoya Horiguchi wrote:
> pte_offset_map_lock() finds and takes ptl, and returns pte.
> But some callers return without unlocking the ptl when pte == NULL,
> which seems weird.
>
> Git history said that !pte check in change_pte_range() was introduced in
> commit 1ad9f620c3a2 ("mm: numa: recheck for transhuge pages under lock
> during protection changes") and still remains after commit 175ad4f1e7a2
> ("mm: mprotect: use pmd_trans_unstable instead of taking the pmd_lock")
> which partially reverts 1ad9f620c3a2. So I think that it's just dead code.
>
> Many other caller of pte_offset_map_lock() never check NULL return, so
> let's do likewise.
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/memory.c | 2 --
> mm/mprotect.c | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git v4.11-rc6-mmotm-2017-04-13-14-50/mm/memory.c v4.11-rc6-mmotm-2017-04-13-14-50_patched/mm/memory.c
> index 8ae6700..c17fad1d 100644
> --- v4.11-rc6-mmotm-2017-04-13-14-50/mm/memory.c
> +++ v4.11-rc6-mmotm-2017-04-13-14-50_patched/mm/memory.c
> @@ -4040,8 +4040,6 @@ static int __follow_pte_pmd(struct mm_struct *mm, unsigned long address,
> goto out;
>
> ptep = pte_offset_map_lock(mm, pmd, address, ptlp);
> - if (!ptep)
> - goto out;
> if (!pte_present(*ptep))
> goto unlock;
> *ptepp = ptep;
> diff --git v4.11-rc6-mmotm-2017-04-13-14-50/mm/mprotect.c v4.11-rc6-mmotm-2017-04-13-14-50_patched/mm/mprotect.c
> index 8fd010f..d60a1ee 100644
> --- v4.11-rc6-mmotm-2017-04-13-14-50/mm/mprotect.c
> +++ v4.11-rc6-mmotm-2017-04-13-14-50_patched/mm/mprotect.c
> @@ -58,8 +58,6 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
> * reading.
> */
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> - if (!pte)
> - return 0;
>
> /* Get target node for single threaded private VMAs */
> if (prot_numa && !(vma->vm_flags & VM_SHARED) &&
>
--
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>
^ permalink raw reply
* Re: [PATCH v5 02/11] mm: mempolicy: add queue_pages_node_check()
From: Anshuman Khandual @ 2017-05-19 13:13 UTC (permalink / raw)
To: Anshuman Khandual, Zi Yan, n-horiguchi, kirill.shutemov,
linux-kernel, linux-mm
Cc: akpm, minchan, vbabka, mgorman, mhocko, zi.yan, dnellans
In-Reply-To: <f7a78cb0-0d91-bdbd-4a38-27f94fcefa8a@linux.vnet.ibm.com>
On 04/21/2017 09:34 AM, Anshuman Khandual wrote:
> On 04/21/2017 02:17 AM, Zi Yan wrote:
>> From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>>
>> Introduce a separate check routine related to MPOL_MF_INVERT flag.
>> This patch just does cleanup, no behavioral change.
>
> Can you please send it separately first, this should be debated
> and merged quickly and not hang on to the series if we have to
> respin again.
>
> Reviewed-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Mel/Andrew,
This does not have any functional changes and very much independent.
Can this clean up be accepted as is ? In that case we will have to
carry one less patch in the series which can make the review process
simpler.
- Anshuman
--
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>
^ permalink raw reply
* Re: [PATCH v5 01/11] mm: x86: move _PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1
From: Anshuman Khandual @ 2017-05-19 13:07 UTC (permalink / raw)
To: Zi Yan, n-horiguchi, kirill.shutemov, linux-kernel, linux-mm
Cc: akpm, minchan, vbabka, mgorman, mhocko, khandual, zi.yan,
dnellans, Dave Hansen, andi.kleen
In-Reply-To: <20170420204752.79703-2-zi.yan@sent.com>
On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>
> pmd_present() checks _PAGE_PSE along with _PAGE_PRESENT to avoid
> false negative return when it races with thp spilt
> (during which _PAGE_PRESENT is temporary cleared.) I don't think that
> dropping _PAGE_PSE check in pmd_present() works well because it can
> hurt optimization of tlb handling in thp split.
> In the current kernel, bits 1-4 are not used in non-present format
> since commit 00839ee3b299 ("x86/mm: Move swap offset/type up in PTE to
> work around erratum"). So let's move _PAGE_SWP_SOFT_DIRTY to bit 1.
> Bit 7 is used as reserved (always clear), so please don't use it for
> other purpose.
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Zi Yan <zi.yan@cs.rutgers.edu>
+Dave Hansen
+Andi Kleen
Dave/Andi/Kiril,
Does this change looks okay ? Its been on the list for some time
now. Could you please have a look into this and lets us know your
inputs/suggestions/comments ? Thank you.
- Anshuman
--
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>
^ permalink raw reply
* Re: [PATCH] ib/core: not to set page dirty bit if it's already set.
From: Christoph Hellwig @ 2017-05-19 13:05 UTC (permalink / raw)
To: Qing Huang
Cc: linux-rdma, linux-kernel, dledford, sean.hefty, artemyko,
linux-mm
In-Reply-To: <20170518233353.14370-1-qing.huang@oracle.com>
On Thu, May 18, 2017 at 04:33:53PM -0700, Qing Huang wrote:
> This change will optimize kernel memory deregistration operations.
> __ib_umem_release() used to call set_page_dirty_lock() against every
> writable page in its memory region. Its purpose is to keep data
> synced between CPU and DMA device when swapping happens after mem
> deregistration ops. Now we choose not to set page dirty bit if it's
> already set by kernel prior to calling __ib_umem_release(). This
> reduces memory deregistration time by half or even more when we ran
> application simulation test program.
As far as I can tell this code doesn't even need set_page_dirty_lock
and could just use set_page_dirty
>
> Signed-off-by: Qing Huang <qing.huang@oracle.com>
> ---
> drivers/infiniband/core/umem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 3dbf811..21e60b1 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -58,7 +58,7 @@ static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int d
> for_each_sg(umem->sg_head.sgl, sg, umem->npages, i) {
>
> page = sg_page(sg);
> - if (umem->writable && dirty)
> + if (!PageDirty(page) && umem->writable && dirty)
> set_page_dirty_lock(page);
> put_page(page);
> }
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
--
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>
^ permalink raw reply
* Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF
From: Tetsuo Handa @ 2017-05-19 13:02 UTC (permalink / raw)
To: mhocko, akpm; +Cc: hannes, guro, vdavydov.dev, linux-mm, linux-kernel, mhocko
In-Reply-To: <20170519112604.29090-3-mhocko@kernel.org>
Michal Hocko wrote:
> Any allocation failure during the #PF path will return with VM_FAULT_OOM
> which in turn results in pagefault_out_of_memory. This can happen for
> 2 different reasons. a) Memcg is out of memory and we rely on
> mem_cgroup_oom_synchronize to perform the memcg OOM handling or b)
> normal allocation fails.
>
> The later is quite problematic because allocation paths already trigger
> out_of_memory and the page allocator tries really hard to not fail
We made many memory allocation requests from page fault path (e.g. XFS)
__GFP_FS some time ago, didn't we? But if I recall correctly (I couldn't
find the message), there are some allocation requests from page fault path
which cannot use __GFP_FS. Then, not all allocation requests can call
oom_kill_process() and reaching pagefault_out_of_memory() will be
inevitable.
> allocations. Anyway, if the OOM killer has been already invoked there
> is no reason to invoke it again from the #PF path. Especially when the
> OOM condition might be gone by that time and we have no way to find out
> other than allocate.
>
> Moreover if the allocation failed and the OOM killer hasn't been
> invoked then we are unlikely to do the right thing from the #PF context
> because we have already lost the allocation context and restictions and
> therefore might oom kill a task from a different NUMA domain.
If we carry a flag via task_struct that indicates whether it is an memory
allocation request from page fault and allocation failure is not acceptable,
we can call out_of_memory() from page allocator path.
> - if (!mutex_trylock(&oom_lock))
> + if (fatal_signal_pending)
fatal_signal_pending(current)
By the way, can page fault occur after reaching do_exit()? When a thread
reached do_exit(), fatal_signal_pending(current) becomes false, doesn't it?
--
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>
^ permalink raw reply
* Re: [PATCH 0/2] fix premature OOM killer
From: Michal Hocko @ 2017-05-19 12:47 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: akpm, hannes, guro, vdavydov.dev, linux-mm, linux-kernel
In-Reply-To: <201705192037.FAG43296.QOLOMOFJFtVSHF@I-love.SAKURA.ne.jp>
On Fri 19-05-17 20:37:21, Tetsuo Handa wrote:
> and patch 2 is wrong.
Why?
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply
* Re: [PATCH 1/2] mm, oom: make sure that the oom victim uses memory reserves
From: Michal Hocko @ 2017-05-19 12:46 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: akpm, hannes, guro, vdavydov.dev, linux-mm, linux-kernel
In-Reply-To: <201705192112.IAF69238.OQOHSJLFOFFMtV@I-love.SAKURA.ne.jp>
On Fri 19-05-17 21:12:36, Tetsuo Handa wrote:
> >From 41b663d0324bbaa29c01d7fee01e897b8b3b7397 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Fri, 19 May 2017 21:06:49 +0900
> Subject: [PATCH] mm,page_alloc: Make sure OOM victim can try allocations with
> no watermarks once
>
> Roman Gushchin has reported that the OOM killer can trivially selects next
> OOM victim when a thread doing memory allocation from page fault path was
> selected as first OOM victim.
>
> ----------
> [ 25.721494] allocate invoked oom-killer: gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
> [ 25.725658] allocate cpuset=/ mems_allowed=0
> [ 25.727033] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
> [ 25.729215] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [ 25.729598] Call Trace:
> [ 25.729598] dump_stack+0x63/0x82
> [ 25.729598] dump_header+0x97/0x21a
> [ 25.729598] ? do_try_to_free_pages+0x2d7/0x360
> [ 25.729598] ? security_capable_noaudit+0x45/0x60
> [ 25.729598] oom_kill_process+0x219/0x3e0
> [ 25.729598] out_of_memory+0x11d/0x480
> [ 25.729598] __alloc_pages_slowpath+0xc84/0xd40
> [ 25.729598] __alloc_pages_nodemask+0x245/0x260
> [ 25.729598] alloc_pages_vma+0xa2/0x270
> [ 25.729598] __handle_mm_fault+0xca9/0x10c0
> [ 25.729598] handle_mm_fault+0xf3/0x210
> [ 25.729598] __do_page_fault+0x240/0x4e0
> [ 25.729598] trace_do_page_fault+0x37/0xe0
> [ 25.729598] do_async_page_fault+0x19/0x70
> [ 25.729598] async_page_fault+0x28/0x30
> (...snipped...)
> [ 25.781882] Out of memory: Kill process 492 (allocate) score 899 or sacrifice child
> [ 25.783874] Killed process 492 (allocate) total-vm:2052368kB, anon-rss:1894576kB, file-rss:4kB, shmem-rss:0kB
> [ 25.785680] allocate: page allocation failure: order:0, mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null)
> [ 25.786797] allocate cpuset=/ mems_allowed=0
> [ 25.787246] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
> [ 25.787935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [ 25.788867] Call Trace:
> [ 25.789119] dump_stack+0x63/0x82
> [ 25.789451] warn_alloc+0x114/0x1b0
> [ 25.789451] __alloc_pages_slowpath+0xd32/0xd40
> [ 25.789451] __alloc_pages_nodemask+0x245/0x260
> [ 25.789451] alloc_pages_vma+0xa2/0x270
> [ 25.789451] __handle_mm_fault+0xca9/0x10c0
> [ 25.789451] handle_mm_fault+0xf3/0x210
> [ 25.789451] __do_page_fault+0x240/0x4e0
> [ 25.789451] trace_do_page_fault+0x37/0xe0
> [ 25.789451] do_async_page_fault+0x19/0x70
> [ 25.789451] async_page_fault+0x28/0x30
> (...snipped...)
> [ 25.810868] oom_reaper: reaped process 492 (allocate), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
> (...snipped...)
> [ 25.817589] allocate invoked oom-killer: gfp_mask=0x0(), nodemask=(null), order=0, oom_score_adj=0
> [ 25.818821] allocate cpuset=/ mems_allowed=0
> [ 25.819259] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
> [ 25.819847] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [ 25.820549] Call Trace:
> [ 25.820733] dump_stack+0x63/0x82
> [ 25.820961] dump_header+0x97/0x21a
> [ 25.820961] ? security_capable_noaudit+0x45/0x60
> [ 25.820961] oom_kill_process+0x219/0x3e0
> [ 25.820961] out_of_memory+0x11d/0x480
> [ 25.820961] pagefault_out_of_memory+0x68/0x80
> [ 25.820961] mm_fault_error+0x8f/0x190
> [ 25.820961] ? handle_mm_fault+0xf3/0x210
> [ 25.820961] __do_page_fault+0x4b2/0x4e0
> [ 25.820961] trace_do_page_fault+0x37/0xe0
> [ 25.820961] do_async_page_fault+0x19/0x70
> [ 25.820961] async_page_fault+0x28/0x30
> (...snipped...)
> [ 25.863078] Out of memory: Kill process 233 (firewalld) score 10 or sacrifice child
> [ 25.863634] Killed process 233 (firewalld) total-vm:246076kB, anon-rss:20956kB, file-rss:0kB, shmem-rss:0kB
> ----------
>
> There is a race window that the OOM reaper completes reclaiming the first
> victim's memory while nothing but mutex_trylock() prevents the first victim
> from calling out_of_memory() from pagefault_out_of_memory() after memory
> allocation for page fault path failed due to being selected as an OOM
> victim.
>
> This is a side effect of commit 9a67f6488eca926f ("mm: consolidate
> GFP_NOFAIL checks in the allocator slowpath") because that commit
> silently changed the behavior from
>
> /* Avoid allocations with no watermarks from looping endlessly */
>
> to
>
> /*
> * Give up allocations without trying memory reserves if selected
> * as an OOM victim
> */
>
> in __alloc_pages_slowpath() by moving the location to check TIF_MEMDIE
> flag. I have noticed this change but I didn't post a patch because
> I thought it is an acceptable change other than noise by warn_alloc()
> because !__GFP_NOFAIL allocations are allowed to fail.
> But we overlooked that failing memory allocation from page fault path
> makes difference due to the race window explained above.
>
> While it might be possible to add a check to pagefault_out_of_memory()
> that prevents the first victim from calling out_of_memory() or remove
> out_of_memory() from pagefault_out_of_memory(), changing
> pagefault_out_of_memory() does not suppress noise by warn_alloc() when
> allocating thread was selected as an OOM victim. There is little point
> with printing similar backtraces and memory information from both
> out_of_memory() and warn_alloc().
>
> Instead, if we guarantee that current thread can try allocations with
> no watermarks once when current thread looping inside
> __alloc_pages_slowpath() was selected as an OOM victim, we can follow
> "who can use memory reserves" rules and suppress noise by warn_alloc()
> and prevent memory allocations from page fault path from calling
> pagefault_out_of_memory().
>
> If we take the comment literally, this patch would do
>
> - if (test_thread_flag(TIF_MEMDIE))
> - goto nopage;
> + if (alloc_flags == ALLOC_NO_WATERMARKS || (gfp_mask & __GFP_NOMEMALLOC))
> + goto nopage;
>
> because gfp_pfmemalloc_allowed() returns false if __GFP_NOMEMALLOC is
> given. But if I recall correctly (I couldn't find the message), the
> condition is meant to apply to only OOM victims despite the comment.
> Therefore, this patch preserves TIF_MEMDIE check.
>
> Reported-by: Roman Gushchin <guro@fb.com>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Michal Hocko <mhocko@suse.com>
> Fixes: 9a67f6488eca926f ("mm: consolidate GFP_NOFAIL checks in the allocator slowpath")
> Cc: stable # v4.11
I cannot say I would love how this gets convoluted but let's go with
what you have here and think about a cleaner version later.
Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> ---
> mm/page_alloc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f9e450c..b7a6f58 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3870,7 +3870,9 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
> goto got_pg;
>
> /* Avoid allocations with no watermarks from looping endlessly */
> - if (test_thread_flag(TIF_MEMDIE))
> + if (test_thread_flag(TIF_MEMDIE) &&
> + (alloc_flags == ALLOC_NO_WATERMARKS ||
> + (gfp_mask & __GFP_NOMEMALLOC)))
> goto nopage;
>
> /* Retry as long as the OOM killer is making progress */
> --
> 1.8.3.1
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply
* Re: [PATCH 1/2] mm, oom: make sure that the oom victim uses memory reserves
From: Tetsuo Handa @ 2017-05-19 12:12 UTC (permalink / raw)
To: mhocko, akpm; +Cc: hannes, guro, vdavydov.dev, linux-mm, linux-kernel, mhocko
In-Reply-To: <20170519112604.29090-2-mhocko@kernel.org>
>From 41b663d0324bbaa29c01d7fee01e897b8b3b7397 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Fri, 19 May 2017 21:06:49 +0900
Subject: [PATCH] mm,page_alloc: Make sure OOM victim can try allocations with
no watermarks once
Roman Gushchin has reported that the OOM killer can trivially selects next
OOM victim when a thread doing memory allocation from page fault path was
selected as first OOM victim.
----------
[ 25.721494] allocate invoked oom-killer: gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
[ 25.725658] allocate cpuset=/ mems_allowed=0
[ 25.727033] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.729215] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.729598] Call Trace:
[ 25.729598] dump_stack+0x63/0x82
[ 25.729598] dump_header+0x97/0x21a
[ 25.729598] ? do_try_to_free_pages+0x2d7/0x360
[ 25.729598] ? security_capable_noaudit+0x45/0x60
[ 25.729598] oom_kill_process+0x219/0x3e0
[ 25.729598] out_of_memory+0x11d/0x480
[ 25.729598] __alloc_pages_slowpath+0xc84/0xd40
[ 25.729598] __alloc_pages_nodemask+0x245/0x260
[ 25.729598] alloc_pages_vma+0xa2/0x270
[ 25.729598] __handle_mm_fault+0xca9/0x10c0
[ 25.729598] handle_mm_fault+0xf3/0x210
[ 25.729598] __do_page_fault+0x240/0x4e0
[ 25.729598] trace_do_page_fault+0x37/0xe0
[ 25.729598] do_async_page_fault+0x19/0x70
[ 25.729598] async_page_fault+0x28/0x30
(...snipped...)
[ 25.781882] Out of memory: Kill process 492 (allocate) score 899 or sacrifice child
[ 25.783874] Killed process 492 (allocate) total-vm:2052368kB, anon-rss:1894576kB, file-rss:4kB, shmem-rss:0kB
[ 25.785680] allocate: page allocation failure: order:0, mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null)
[ 25.786797] allocate cpuset=/ mems_allowed=0
[ 25.787246] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.787935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.788867] Call Trace:
[ 25.789119] dump_stack+0x63/0x82
[ 25.789451] warn_alloc+0x114/0x1b0
[ 25.789451] __alloc_pages_slowpath+0xd32/0xd40
[ 25.789451] __alloc_pages_nodemask+0x245/0x260
[ 25.789451] alloc_pages_vma+0xa2/0x270
[ 25.789451] __handle_mm_fault+0xca9/0x10c0
[ 25.789451] handle_mm_fault+0xf3/0x210
[ 25.789451] __do_page_fault+0x240/0x4e0
[ 25.789451] trace_do_page_fault+0x37/0xe0
[ 25.789451] do_async_page_fault+0x19/0x70
[ 25.789451] async_page_fault+0x28/0x30
(...snipped...)
[ 25.810868] oom_reaper: reaped process 492 (allocate), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
(...snipped...)
[ 25.817589] allocate invoked oom-killer: gfp_mask=0x0(), nodemask=(null), order=0, oom_score_adj=0
[ 25.818821] allocate cpuset=/ mems_allowed=0
[ 25.819259] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.819847] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.820549] Call Trace:
[ 25.820733] dump_stack+0x63/0x82
[ 25.820961] dump_header+0x97/0x21a
[ 25.820961] ? security_capable_noaudit+0x45/0x60
[ 25.820961] oom_kill_process+0x219/0x3e0
[ 25.820961] out_of_memory+0x11d/0x480
[ 25.820961] pagefault_out_of_memory+0x68/0x80
[ 25.820961] mm_fault_error+0x8f/0x190
[ 25.820961] ? handle_mm_fault+0xf3/0x210
[ 25.820961] __do_page_fault+0x4b2/0x4e0
[ 25.820961] trace_do_page_fault+0x37/0xe0
[ 25.820961] do_async_page_fault+0x19/0x70
[ 25.820961] async_page_fault+0x28/0x30
(...snipped...)
[ 25.863078] Out of memory: Kill process 233 (firewalld) score 10 or sacrifice child
[ 25.863634] Killed process 233 (firewalld) total-vm:246076kB, anon-rss:20956kB, file-rss:0kB, shmem-rss:0kB
----------
There is a race window that the OOM reaper completes reclaiming the first
victim's memory while nothing but mutex_trylock() prevents the first victim
from calling out_of_memory() from pagefault_out_of_memory() after memory
allocation for page fault path failed due to being selected as an OOM
victim.
This is a side effect of commit 9a67f6488eca926f ("mm: consolidate
GFP_NOFAIL checks in the allocator slowpath") because that commit
silently changed the behavior from
/* Avoid allocations with no watermarks from looping endlessly */
to
/*
* Give up allocations without trying memory reserves if selected
* as an OOM victim
*/
in __alloc_pages_slowpath() by moving the location to check TIF_MEMDIE
flag. I have noticed this change but I didn't post a patch because
I thought it is an acceptable change other than noise by warn_alloc()
because !__GFP_NOFAIL allocations are allowed to fail.
But we overlooked that failing memory allocation from page fault path
makes difference due to the race window explained above.
While it might be possible to add a check to pagefault_out_of_memory()
that prevents the first victim from calling out_of_memory() or remove
out_of_memory() from pagefault_out_of_memory(), changing
pagefault_out_of_memory() does not suppress noise by warn_alloc() when
allocating thread was selected as an OOM victim. There is little point
with printing similar backtraces and memory information from both
out_of_memory() and warn_alloc().
Instead, if we guarantee that current thread can try allocations with
no watermarks once when current thread looping inside
__alloc_pages_slowpath() was selected as an OOM victim, we can follow
"who can use memory reserves" rules and suppress noise by warn_alloc()
and prevent memory allocations from page fault path from calling
pagefault_out_of_memory().
If we take the comment literally, this patch would do
- if (test_thread_flag(TIF_MEMDIE))
- goto nopage;
+ if (alloc_flags == ALLOC_NO_WATERMARKS || (gfp_mask & __GFP_NOMEMALLOC))
+ goto nopage;
because gfp_pfmemalloc_allowed() returns false if __GFP_NOMEMALLOC is
given. But if I recall correctly (I couldn't find the message), the
condition is meant to apply to only OOM victims despite the comment.
Therefore, this patch preserves TIF_MEMDIE check.
Reported-by: Roman Gushchin <guro@fb.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Michal Hocko <mhocko@suse.com>
Fixes: 9a67f6488eca926f ("mm: consolidate GFP_NOFAIL checks in the allocator slowpath")
Cc: stable # v4.11
---
mm/page_alloc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f9e450c..b7a6f58 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3870,7 +3870,9 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
goto got_pg;
/* Avoid allocations with no watermarks from looping endlessly */
- if (test_thread_flag(TIF_MEMDIE))
+ if (test_thread_flag(TIF_MEMDIE) &&
+ (alloc_flags == ALLOC_NO_WATERMARKS ||
+ (gfp_mask & __GFP_NOMEMALLOC)))
goto nopage;
/* Retry as long as the OOM killer is making progress */
--
1.8.3.1
--
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>
^ permalink raw reply related
* Re: [PATCH v2 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator
From: Michal Hocko @ 2017-05-19 11:59 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrew Morton, linux-mm, linux-api, linux-kernel, cgroups,
Li Zefan, Mel Gorman, David Rientjes, Christoph Lameter,
Hugh Dickins, Andrea Arcangeli, Anshuman Khandual,
Kirill A. Shutemov
In-Reply-To: <20170517081140.30654-4-vbabka@suse.cz>
On Wed 17-05-17 10:11:37, Vlastimil Babka wrote:
> The main allocator function __alloc_pages_nodemask() takes a zonelist pointer
> as one of its parameters. All of its callers directly or indirectly obtain the
> zonelist via node_zonelist() using a preferred node id and gfp_mask. We can
> make the code a bit simpler by doing the zonelist lookup in
> __alloc_pages_nodemask(), passing it a preferred node id instead (gfp_mask is
> already another parameter).
>
> There are some code size benefits thanks to removal of inlined node_zonelist():
>
> bloat-o-meter add/remove: 2/2 grow/shrink: 4/36 up/down: 399/-1351 (-952)
>
> This will also make things simpler if we proceed with converting cpusets to
> zonelists.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Makes sense to me
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> include/linux/gfp.h | 11 +++++------
> include/linux/mempolicy.h | 6 +++---
> mm/hugetlb.c | 15 +++++++++------
> mm/memory_hotplug.c | 6 ++----
> mm/mempolicy.c | 41 +++++++++++++++++++----------------------
> mm/page_alloc.c | 10 +++++-----
> 6 files changed, 43 insertions(+), 46 deletions(-)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 2b1a44f5bdb6..666af3c39d00 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -432,14 +432,13 @@ static inline void arch_alloc_page(struct page *page, int order) { }
> #endif
>
> struct page *
> -__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
> - struct zonelist *zonelist, nodemask_t *nodemask);
> +__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> + nodemask_t *nodemask);
>
> static inline struct page *
> -__alloc_pages(gfp_t gfp_mask, unsigned int order,
> - struct zonelist *zonelist)
> +__alloc_pages(gfp_t gfp_mask, unsigned int order, int preferred_nid)
> {
> - return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
> + return __alloc_pages_nodemask(gfp_mask, order, preferred_nid, NULL);
> }
>
> /*
> @@ -452,7 +451,7 @@ __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
> VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> VM_WARN_ON(!node_online(nid));
>
> - return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
> + return __alloc_pages(gfp_mask, order, nid);
> }
>
> /*
> diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
> index 5f4d8281832b..ecb6cbeede5a 100644
> --- a/include/linux/mempolicy.h
> +++ b/include/linux/mempolicy.h
> @@ -146,7 +146,7 @@ extern void mpol_rebind_task(struct task_struct *tsk, const nodemask_t *new,
> enum mpol_rebind_step step);
> extern void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new);
>
> -extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
> +extern int huge_node(struct vm_area_struct *vma,
> unsigned long addr, gfp_t gfp_flags,
> struct mempolicy **mpol, nodemask_t **nodemask);
> extern bool init_nodemask_of_mempolicy(nodemask_t *mask);
> @@ -269,13 +269,13 @@ static inline void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new)
> {
> }
>
> -static inline struct zonelist *huge_zonelist(struct vm_area_struct *vma,
> +static inline int huge_node(struct vm_area_struct *vma,
> unsigned long addr, gfp_t gfp_flags,
> struct mempolicy **mpol, nodemask_t **nodemask)
> {
> *mpol = NULL;
> *nodemask = NULL;
> - return node_zonelist(0, gfp_flags);
> + return 0;
> }
>
> static inline bool init_nodemask_of_mempolicy(nodemask_t *m)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index e5828875f7bb..9f1f399bb913 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -904,6 +904,8 @@ static struct page *dequeue_huge_page_vma(struct hstate *h,
> struct page *page = NULL;
> struct mempolicy *mpol;
> nodemask_t *nodemask;
> + gfp_t gfp_mask;
> + int nid;
> struct zonelist *zonelist;
> struct zone *zone;
> struct zoneref *z;
> @@ -924,12 +926,13 @@ static struct page *dequeue_huge_page_vma(struct hstate *h,
>
> retry_cpuset:
> cpuset_mems_cookie = read_mems_allowed_begin();
> - zonelist = huge_zonelist(vma, address,
> - htlb_alloc_mask(h), &mpol, &nodemask);
> + gfp_mask = htlb_alloc_mask(h);
> + nid = huge_node(vma, address, gfp_mask, &mpol, &nodemask);
> + zonelist = node_zonelist(nid, gfp_mask);
>
> for_each_zone_zonelist_nodemask(zone, z, zonelist,
> MAX_NR_ZONES - 1, nodemask) {
> - if (cpuset_zone_allowed(zone, htlb_alloc_mask(h))) {
> + if (cpuset_zone_allowed(zone, gfp_mask)) {
> page = dequeue_huge_page_node(h, zone_to_nid(zone));
> if (page) {
> if (avoid_reserve)
> @@ -1545,13 +1548,13 @@ static struct page *__hugetlb_alloc_buddy_huge_page(struct hstate *h,
> do {
> struct page *page;
> struct mempolicy *mpol;
> - struct zonelist *zl;
> + int nid;
> nodemask_t *nodemask;
>
> cpuset_mems_cookie = read_mems_allowed_begin();
> - zl = huge_zonelist(vma, addr, gfp, &mpol, &nodemask);
> + nid = huge_node(vma, addr, gfp, &mpol, &nodemask);
> mpol_cond_put(mpol);
> - page = __alloc_pages_nodemask(gfp, order, zl, nodemask);
> + page = __alloc_pages_nodemask(gfp, order, nid, nodemask);
> if (page)
> return page;
> } while (read_mems_allowed_retry(cpuset_mems_cookie));
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 717c5e301aa8..ba9e09817f37 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1596,11 +1596,9 @@ static struct page *new_node_page(struct page *page, unsigned long private,
> gfp_mask |= __GFP_HIGHMEM;
>
> if (!nodes_empty(nmask))
> - new_page = __alloc_pages_nodemask(gfp_mask, 0,
> - node_zonelist(nid, gfp_mask), &nmask);
> + new_page = __alloc_pages_nodemask(gfp_mask, 0, nid, &nmask);
> if (!new_page)
> - new_page = __alloc_pages(gfp_mask, 0,
> - node_zonelist(nid, gfp_mask));
> + new_page = __alloc_pages(gfp_mask, 0, nid);
>
> return new_page;
> }
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index d77177c7283b..c60807625fd5 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1669,9 +1669,9 @@ static nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy *policy)
> return NULL;
> }
>
> -/* Return a zonelist indicated by gfp for node representing a mempolicy */
> -static struct zonelist *policy_zonelist(gfp_t gfp, struct mempolicy *policy,
> - int nd)
> +/* Return the node id preferred by the given mempolicy, or the given id */
> +static int policy_node(gfp_t gfp, struct mempolicy *policy,
> + int nd)
> {
> if (policy->mode == MPOL_PREFERRED && !(policy->flags & MPOL_F_LOCAL))
> nd = policy->v.preferred_node;
> @@ -1684,7 +1684,7 @@ static struct zonelist *policy_zonelist(gfp_t gfp, struct mempolicy *policy,
> WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));
> }
>
> - return node_zonelist(nd, gfp);
> + return nd;
> }
>
> /* Do dynamic interleaving for a process */
> @@ -1791,38 +1791,37 @@ static inline unsigned interleave_nid(struct mempolicy *pol,
>
> #ifdef CONFIG_HUGETLBFS
> /*
> - * huge_zonelist(@vma, @addr, @gfp_flags, @mpol)
> + * huge_node(@vma, @addr, @gfp_flags, @mpol)
> * @vma: virtual memory area whose policy is sought
> * @addr: address in @vma for shared policy lookup and interleave policy
> * @gfp_flags: for requested zone
> * @mpol: pointer to mempolicy pointer for reference counted mempolicy
> * @nodemask: pointer to nodemask pointer for MPOL_BIND nodemask
> *
> - * Returns a zonelist suitable for a huge page allocation and a pointer
> + * Returns a nid suitable for a huge page allocation and a pointer
> * to the struct mempolicy for conditional unref after allocation.
> * If the effective policy is 'BIND, returns a pointer to the mempolicy's
> * @nodemask for filtering the zonelist.
> *
> * Must be protected by read_mems_allowed_begin()
> */
> -struct zonelist *huge_zonelist(struct vm_area_struct *vma, unsigned long addr,
> - gfp_t gfp_flags, struct mempolicy **mpol,
> - nodemask_t **nodemask)
> +int huge_node(struct vm_area_struct *vma, unsigned long addr, gfp_t gfp_flags,
> + struct mempolicy **mpol, nodemask_t **nodemask)
> {
> - struct zonelist *zl;
> + int nid;
>
> *mpol = get_vma_policy(vma, addr);
> *nodemask = NULL; /* assume !MPOL_BIND */
>
> if (unlikely((*mpol)->mode == MPOL_INTERLEAVE)) {
> - zl = node_zonelist(interleave_nid(*mpol, vma, addr,
> - huge_page_shift(hstate_vma(vma))), gfp_flags);
> + nid = interleave_nid(*mpol, vma, addr,
> + huge_page_shift(hstate_vma(vma)));
> } else {
> - zl = policy_zonelist(gfp_flags, *mpol, numa_node_id());
> + nid = policy_node(gfp_flags, *mpol, numa_node_id());
> if ((*mpol)->mode == MPOL_BIND)
> *nodemask = &(*mpol)->v.nodes;
> }
> - return zl;
> + return nid;
> }
>
> /*
> @@ -1924,12 +1923,10 @@ bool mempolicy_nodemask_intersects(struct task_struct *tsk,
> static struct page *alloc_page_interleave(gfp_t gfp, unsigned order,
> unsigned nid)
> {
> - struct zonelist *zl;
> struct page *page;
>
> - zl = node_zonelist(nid, gfp);
> - page = __alloc_pages(gfp, order, zl);
> - if (page && page_zone(page) == zonelist_zone(&zl->_zonerefs[0]))
> + page = __alloc_pages(gfp, order, nid);
> + if (page && page_to_nid(page) == nid)
> inc_zone_page_state(page, NUMA_INTERLEAVE_HIT);
> return page;
> }
> @@ -1963,8 +1960,8 @@ 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;
> - struct zonelist *zl;
> nodemask_t *nmask;
>
> retry_cpuset:
> @@ -2007,8 +2004,8 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
> }
>
> nmask = policy_nodemask(gfp, pol);
> - zl = policy_zonelist(gfp, pol, node);
> - page = __alloc_pages_nodemask(gfp, order, zl, nmask);
> + preferred_nid = policy_node(gfp, pol, node);
> + page = __alloc_pages_nodemask(gfp, order, preferred_nid, nmask);
> mpol_cond_put(pol);
> out:
> if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
> @@ -2055,7 +2052,7 @@ struct page *alloc_pages_current(gfp_t gfp, unsigned order)
> page = alloc_page_interleave(gfp, order, interleave_nodes(pol));
> else
> page = __alloc_pages_nodemask(gfp, order,
> - policy_zonelist(gfp, pol, numa_node_id()),
> + policy_node(gfp, pol, numa_node_id()),
> policy_nodemask(gfp, pol));
>
> if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 43aa767c3188..0aceca1076dc 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3962,12 +3962,12 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> }
>
> static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order,
> - struct zonelist *zonelist, nodemask_t *nodemask,
> + int preferred_nid, nodemask_t *nodemask,
> struct alloc_context *ac, gfp_t *alloc_mask,
> unsigned int *alloc_flags)
> {
> ac->high_zoneidx = gfp_zone(gfp_mask);
> - ac->zonelist = zonelist;
> + ac->zonelist = node_zonelist(preferred_nid, gfp_mask);
> ac->nodemask = nodemask;
> ac->migratetype = gfpflags_to_migratetype(gfp_mask);
>
> @@ -4012,8 +4012,8 @@ static inline void finalise_ac(gfp_t gfp_mask,
> * This is the 'heart' of the zoned buddy allocator.
> */
> struct page *
> -__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
> - struct zonelist *zonelist, nodemask_t *nodemask)
> +__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> + nodemask_t *nodemask)
> {
> struct page *page;
> unsigned int alloc_flags = ALLOC_WMARK_LOW;
> @@ -4021,7 +4021,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
> struct alloc_context ac = { };
>
> gfp_mask &= gfp_allowed_mask;
> - if (!prepare_alloc_pages(gfp_mask, order, zonelist, nodemask, &ac, &alloc_mask, &alloc_flags))
> + if (!prepare_alloc_pages(gfp_mask, order, preferred_nid, nodemask, &ac, &alloc_mask, &alloc_flags))
> return NULL;
>
> finalise_ac(gfp_mask, order, &ac);
> --
> 2.12.2
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply
* Re: [PATCH v2 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
From: Michal Hocko @ 2017-05-19 11:51 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrew Morton, linux-mm, linux-api, linux-kernel, cgroups,
Li Zefan, Mel Gorman, David Rientjes, Christoph Lameter,
Hugh Dickins, Andrea Arcangeli, Anshuman Khandual,
Kirill A. Shutemov
In-Reply-To: <20170517081140.30654-2-vbabka@suse.cz>
On Wed 17-05-17 10:11:35, Vlastimil Babka wrote:
> Commit e47483bca2cc ("mm, page_alloc: fix premature OOM when racing with cpuset
> mems update") has fixed known recent regressions found by LTP's cpuset01
> testcase. I have however found that by modifying the testcase to use per-vma
> mempolicies via bind(2) instead of per-task mempolicies via set_mempolicy(2),
> the premature OOM still happens and the issue is much older.
>
> The root of the problem is that the cpuset's mems_allowed and mempolicy's
> nodemask can temporarily have no intersection, thus get_page_from_freelist()
> cannot find any usable zone. The current semantic for empty intersection is to
> ignore mempolicy's nodemask and honour cpuset restrictions. This is checked in
> node_zonelist(), but the racy update can happen after we already passed the
> check. Such races should be protected by the seqlock task->mems_allowed_seq,
> but it doesn't work here, because 1) mpol_rebind_mm() does not happen under
> seqlock for write, and doing so would lead to deadlock, as it takes mmap_sem
> for write, while the allocation can have mmap_sem for read when it's taking the
> seqlock for read. And 2) the seqlock cookie of callers of node_zonelist()
> (alloc_pages_vma() and alloc_pages_current()) is different than the one of
> __alloc_pages_slowpath(), so there's still a potential race window.
>
> This patch fixes the issue by having __alloc_pages_slowpath() check for empty
> intersection of cpuset and ac->nodemask before OOM or allocation failure. If
> it's indeed empty, the nodemask is ignored and allocation retried, which mimics
> node_zonelist(). This works fine, because almost all callers of
> __alloc_pages_nodemask are obtaining the nodemask via node_zonelist(). The only
> exception is new_node_page() from hotplug, where the potential violation of
> nodemask isn't an issue, as there's already a fallback allocation attempt
> without any nodemask. If there's a future caller that needs to have its specific
> nodemask honoured over task's cpuset restrictions, we'll have to e.g. add a gfp
> flag for that.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Do we want this backported to the stable tree?
OK I do agree this makes some sense as a quick and easy to backport
workaround.
Acked-by: Michal Hocko <mhocko@suse.com?
> ---
> mm/page_alloc.c | 51 ++++++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index beb2827fd5de..43aa767c3188 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3661,6 +3661,39 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
> return false;
> }
>
> +static inline bool
> +check_retry_cpuset(int cpuset_mems_cookie, struct alloc_context *ac)
> +{
> + /*
> + * It's possible that cpuset's mems_allowed and the nodemask from
> + * mempolicy don't intersect. This should be normally dealt with by
> + * policy_nodemask(), but it's possible to race with cpuset update in
> + * such a way the check therein was true, and then it became false
> + * before we got our cpuset_mems_cookie here.
> + * This assumes that for all allocations, ac->nodemask can come only
> + * from MPOL_BIND mempolicy (whose documented semantics is to be ignored
> + * when it does not intersect with the cpuset restrictions) or the
> + * caller can deal with a violated nodemask.
> + */
> + if (cpusets_enabled() && ac->nodemask &&
> + !cpuset_nodemask_valid_mems_allowed(ac->nodemask)) {
> + ac->nodemask = NULL;
> + return true;
> + }
> +
> + /*
> + * When updating a task's mems_allowed or mempolicy nodemask, it is
> + * possible to race with parallel threads in such a way that our
> + * allocation can fail while the mask is being updated. If we are about
> + * to fail, check if the cpuset changed during allocation and if so,
> + * retry.
> + */
> + if (read_mems_allowed_retry(cpuset_mems_cookie))
> + return true;
> +
> + return false;
> +}
> +
> static inline struct page *
> __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> struct alloc_context *ac)
> @@ -3856,11 +3889,9 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> &compaction_retries))
> goto retry;
>
> - /*
> - * It's possible we raced with cpuset update so the OOM would be
> - * premature (see below the nopage: label for full explanation).
> - */
> - if (read_mems_allowed_retry(cpuset_mems_cookie))
> +
> + /* Deal with possible cpuset update races before we start OOM killing */
> + if (check_retry_cpuset(cpuset_mems_cookie, ac))
> goto retry_cpuset;
>
> /* Reclaim has failed us, start killing things */
> @@ -3879,14 +3910,8 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> }
>
> nopage:
> - /*
> - * When updating a task's mems_allowed or mempolicy nodemask, it is
> - * possible to race with parallel threads in such a way that our
> - * allocation can fail while the mask is being updated. If we are about
> - * to fail, check if the cpuset changed during allocation and if so,
> - * retry.
> - */
> - if (read_mems_allowed_retry(cpuset_mems_cookie))
> + /* Deal with possible cpuset update races before we fail */
> + if (check_retry_cpuset(cpuset_mems_cookie, ac))
> goto retry_cpuset;
>
> /*
> --
> 2.12.2
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply
* Re: [PATCH 0/2] fix premature OOM killer
From: Tetsuo Handa @ 2017-05-19 11:37 UTC (permalink / raw)
To: mhocko, akpm; +Cc: hannes, guro, vdavydov.dev, linux-mm, linux-kernel
In-Reply-To: <20170519112604.29090-1-mhocko@kernel.org>
Michal Hocko wrote:
> Hi,
> this is a follow up for [1]. The first patch is what Tetsuo suggested
> [2], I've just added a changelog for it. This one should be merged
> as soon as possible. The second patch is still an RFC. I _believe_
> that it is the right thing to do but I haven't checked all the PF paths
> which return VM_FAULT_OOM to be sure that there is nobody who would return
> this error when not doing a real allocation.
>
> [1] http://lkml.kernel.org/r/1495034780-9520-1-git-send-email-guro@fb.com
> [2] http://lkml.kernel.org/r/201705182257.HJJ52185.OQStFLFMHVOJOF@I-love.SAKURA.ne.jp
>
>
Patch 1 is insufficient and patch 2 is wrong. Please wait. I'm writing patch 1 now.
--
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>
^ permalink raw reply
* Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption
From: Borislav Petkov @ 2017-05-19 11:30 UTC (permalink / raw)
To: Tom Lendacky, Josh Poimboeuf
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, kexec, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Toshimitsu Kani, Arnd Bergmann,
Jonathan Corbet, Matt Fleming, Michael S. Tsirkin, Joerg Roedel,
Konrad Rzeszutek Wilk, Paolo Bonzini, Larry Woodman,
Brijesh Singh, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin, Alexander Potapenko, Dave Young, Thomas Gleixner,
Dmitry Vyukov
In-Reply-To: <c29edaff-24f2-ee9b-4142-bdbf8c42083f@amd.com>
On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote:
> On 4/18/2017 4:22 PM, Tom Lendacky wrote:
> > Add support to check if SME has been enabled and if memory encryption
> > should be activated (checking of command line option based on the
> > configuration of the default state). If memory encryption is to be
> > activated, then the encryption mask is set and the kernel is encrypted
> > "in place."
> >
> > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> > ---
> > arch/x86/kernel/head_64.S | 1 +
> > arch/x86/mm/mem_encrypt.c | 83 +++++++++++++++++++++++++++++++++++++++++++--
> > 2 files changed, 80 insertions(+), 4 deletions(-)
> >
>
> ...
>
> >
> > -unsigned long __init sme_enable(void)
> > +unsigned long __init sme_enable(struct boot_params *bp)
> > {
> > + const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
> > + unsigned int eax, ebx, ecx, edx;
> > + unsigned long me_mask;
> > + bool active_by_default;
> > + char buffer[16];
>
> So it turns out that when KASLR is enabled (CONFIG_RAMDOMIZE_BASE=y)
> the stack-protector support causes issues with this function because
What issues?
> it is called so early. I can get past it by adding:
>
> CFLAGS_mem_encrypt.o := $(nostackp)
>
> in the arch/x86/mm/Makefile, but that obviously eliminates the support
> for the whole file. Would it be better to split out the sme_enable()
> and other boot routines into a separate file or just apply the
> $(nostackp) to the whole file?
Josh might have a better idea here... CCed.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
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>
^ permalink raw reply
* Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
From: Vlastimil Babka @ 2017-05-19 11:27 UTC (permalink / raw)
To: Christoph Lameter
Cc: Michal Hocko, linux-mm, linux-kernel, cgroups, Li Zefan,
Mel Gorman, David Rientjes, Hugh Dickins, Andrea Arcangeli,
Anshuman Khandual, Kirill A. Shutemov, linux-api
In-Reply-To: <alpine.DEB.2.20.1705181158250.27641@east.gentwo.org>
On 05/18/2017 07:07 PM, Christoph Lameter wrote:
> On Thu, 18 May 2017, Vlastimil Babka wrote:
>
>>> The race is where? If you expand the node set during the move of the
>>> application then you are safe in terms of the legacy apps that did not
>>> include static bindings.
>>
>> No, that expand/shrink by itself doesn't work against parallel
>
> Parallel? I think we are clear that ithis is inherently racy against the
> app changing policies etc etc? There is a huge issue there already. The
> app needs to be well behaved in some heretofore undefined way in order to
> make moves clean.
The code is safe against mbind() changing a vma's mempolicy parallel to
another thread page faulting within that vma, because mbind() takes
mmap_sem for write, and page faults take it for read. The per-task
mempolicy can be changed by set_mempolicy() call which means the task
itself doesn't allocate stuff in parallel.
So, the application never needed to be "well behaved" wrt changing its
own mempolicies.
Now with mempolicy rebinding due to cpuset migrations, the application
cannot be "well behaved" as it has no way to learn about being under a
cpuset, or cpuset change. Any application can be put in a cpuset and we
can't really expect that all would be adapted, even if the necessary
interfaces existed. Thus, the rebinding implementation in the kernel
itself has to be robust against parallel allocations.
>> get_page_from_freelist going through a zonelist. Moving from node 0 to
>> 1, with zonelist containing nodes 1 and 0 in that order:
>>
>> - mempolicy mask is 0
>> - zonelist iteration checks node 1, it's not allowed, skip
>
> There is an allocation from node 1?
Sorry, I missed to mention the full scenario. Let's say the allocation
is on cpu local to node 1, so it gets zonelist from node 1, which
contains nodes 1 and 0 in that order.
> This is not allowed before the move.
> So it should fail. Not skipping to another node.
>
>> - mempolicy mask is 0,1 (expand)
>> - mempolicy mask is 1 (shrink)
>> - zonelist iteration checks node 0, it's not allowed, skip
>> - OOM
>
> Are you talking about a race here between zonelist scanning and the
> moving? That has been there forever.
As far as I can tell from my git archeology in [1] there was always some
kind of protection against the race (generation counters, two-step
protocol, seqlock...), which however had some corner cases. This patch
is merely plugging the last known one.
> And frankly there are gazillions of these races.
I don't know about any other existing race that we don't handle after
this patch.
> The best thing to do is
> to get the cpuset moving logic out of the kernel and into user space.
>
> Understand that this is a heuristic and maybe come up with a list of
> restrictions that make an app safe. An safe app that can be moved must f.e
>
> 1. Not allocate new memory while its being moved
> 2. Not change memory policies after its initialization and while its being
> moved.
As I explainer eariler in this mail, changing mempolicy by app itself is
safe, the problem was always due to cpuset-triggered rebinding.
> 3. Not save memory policy state in some variable (because the logic to
> translate the memory policies for the new context cannot find it).
>
> ...
>
> Again cpuset process migration is a huge mess that you do not want to
> have in the kernel and AFAICT this is a corner case with difficult
> semantics. Better have that in user space...
Moving this out of kernel etc is changing the current semantics and
breaking existing userspace, this patch is a fix within the existing one.
[1] https://marc.info/?l=linux-mm&m=148611344511408&w=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>
>
--
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>
^ permalink raw reply
* Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption
From: Borislav Petkov @ 2017-05-19 11:27 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, kexec, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Toshimitsu Kani, Arnd Bergmann,
Jonathan Corbet, Matt Fleming, Michael S. Tsirkin, Joerg Roedel,
Konrad Rzeszutek Wilk, Paolo Bonzini, Larry Woodman,
Brijesh Singh, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin, Alexander Potapenko, Dave Young, Thomas Gleixner,
Dmitry Vyukov
In-Reply-To: <20170418212223.10190.85121.stgit@tlendack-t1.amdoffice.net>
On Tue, Apr 18, 2017 at 04:22:23PM -0500, Tom Lendacky wrote:
> Add support to check if SME has been enabled and if memory encryption
> should be activated (checking of command line option based on the
> configuration of the default state). If memory encryption is to be
> activated, then the encryption mask is set and the kernel is encrypted
> "in place."
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/kernel/head_64.S | 1 +
> arch/x86/mm/mem_encrypt.c | 83 +++++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 80 insertions(+), 4 deletions(-)
...
> +unsigned long __init sme_enable(struct boot_params *bp)
> {
> + const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
> + unsigned int eax, ebx, ecx, edx;
> + unsigned long me_mask;
> + bool active_by_default;
> + char buffer[16];
> + u64 msr;
> +
> + /* Check for the SME support leaf */
> + eax = 0x80000000;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (eax < 0x8000001f)
> + goto out;
> +
> + /*
> + * Check for the SME feature:
> + * CPUID Fn8000_001F[EAX] - Bit 0
> + * Secure Memory Encryption support
> + * CPUID Fn8000_001F[EBX] - Bits 5:0
> + * Pagetable bit position used to indicate encryption
> + */
> + eax = 0x8000001f;
> + ecx = 0;
> + native_cpuid(&eax, &ebx, &ecx, &edx);
> + if (!(eax & 1))
> + goto out;
<---- newline here.
> + me_mask = 1UL << (ebx & 0x3f);
> +
> + /* Check if SME is enabled */
> + msr = __rdmsr(MSR_K8_SYSCFG);
> + if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
> + goto out;
> +
> + /*
> + * Fixups have not been applied to phys_base yet, so we must obtain
> + * the address to the SME command line option data in the following
> + * way.
> + */
> + asm ("lea sme_cmdline_arg(%%rip), %0"
> + : "=r" (cmdline_arg)
> + : "p" (sme_cmdline_arg));
> + asm ("lea sme_cmdline_on(%%rip), %0"
> + : "=r" (cmdline_on)
> + : "p" (sme_cmdline_on));
> + asm ("lea sme_cmdline_off(%%rip), %0"
> + : "=r" (cmdline_off)
> + : "p" (sme_cmdline_off));
> +
> + if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT))
> + active_by_default = true;
> + else
> + active_by_default = false;
> +
> + cmdline_ptr = (const char *)((u64)bp->hdr.cmd_line_ptr |
> + ((u64)bp->ext_cmd_line_ptr << 32));
> +
> + cmdline_find_option(cmdline_ptr, cmdline_arg, buffer, sizeof(buffer));
> +
> + if (strncmp(buffer, cmdline_on, sizeof(buffer)) == 0)
> + sme_me_mask = me_mask;
Why doesn't simply
if (!strncmp(buffer, "on", 2))
...
work?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
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>
^ permalink raw reply
* [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF
From: Michal Hocko @ 2017-05-19 11:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Johannes Weiner, Roman Gushchin, Tetsuo Handa, Vladimir Davydov,
linux-mm, LKML, Michal Hocko
In-Reply-To: <20170519112604.29090-1-mhocko@kernel.org>
From: Michal Hocko <mhocko@suse.com>
Any allocation failure during the #PF path will return with VM_FAULT_OOM
which in turn results in pagefault_out_of_memory. This can happen for
2 different reasons. a) Memcg is out of memory and we rely on
mem_cgroup_oom_synchronize to perform the memcg OOM handling or b)
normal allocation fails.
The later is quite problematic because allocation paths already trigger
out_of_memory and the page allocator tries really hard to not fail
allocations. Anyway, if the OOM killer has been already invoked there
is no reason to invoke it again from the #PF path. Especially when the
OOM condition might be gone by that time and we have no way to find out
other than allocate.
Moreover if the allocation failed and the OOM killer hasn't been
invoked then we are unlikely to do the right thing from the #PF context
because we have already lost the allocation context and restictions and
therefore might oom kill a task from a different NUMA domain.
An allocation might fail also when the current task is the oom victim
and there are no memory reserves left and we should simply bail out
from the #PF rather than invoking out_of_memory.
This all suggests that there is no legitimate reason to trigger
out_of_memory from pagefault_out_of_memory so drop it. Just to be sure
that no #PF path returns with VM_FAULT_OOM without allocation print a
warning that this is happening before we restart the #PF.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
mm/oom_kill.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 04c9143a8625..0f24bdfaadfd 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1051,25 +1051,22 @@ bool out_of_memory(struct oom_control *oc)
}
/*
- * The pagefault handler calls here because it is out of memory, so kill a
- * memory-hogging task. If oom_lock is held by somebody else, a parallel oom
- * killing is already in progress so do nothing.
+ * The pagefault handler calls here because some allocation has failed. We have
+ * to take care of the memcg OOM here because this is the only safe context without
+ * any locks held but let the oom killer triggered from the allocation context care
+ * about the global OOM.
*/
void pagefault_out_of_memory(void)
{
- struct oom_control oc = {
- .zonelist = NULL,
- .nodemask = NULL,
- .memcg = NULL,
- .gfp_mask = 0,
- .order = 0,
- };
+ static DEFINE_RATELIMIT_STATE(pfoom_rs, DEFAULT_RATELIMIT_INTERVAL,
+ DEFAULT_RATELIMIT_BURST);
if (mem_cgroup_oom_synchronize(true))
return;
- if (!mutex_trylock(&oom_lock))
+ if (fatal_signal_pending)
return;
- out_of_memory(&oc);
- mutex_unlock(&oom_lock);
+
+ if (__ratelimit(&pfoom_rs))
+ pr_warn("Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF\n");
}
--
2.11.0
--
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>
^ permalink raw reply related
* [PATCH 1/2] mm, oom: make sure that the oom victim uses memory reserves
From: Michal Hocko @ 2017-05-19 11:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Johannes Weiner, Roman Gushchin, Tetsuo Handa, Vladimir Davydov,
linux-mm, LKML, Michal Hocko
In-Reply-To: <20170519112604.29090-1-mhocko@kernel.org>
From: Michal Hocko <mhocko@suse.com>
Roman Gushchin has noticed that we kill two tasks when the memory hog
killed from page fault path:
[ 25.721494] allocate invoked oom-killer: gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
[ 25.725658] allocate cpuset=/ mems_allowed=0
[ 25.727033] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.729215] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.729598] Call Trace:
[ 25.729598] dump_stack+0x63/0x82
[ 25.729598] dump_header+0x97/0x21a
[ 25.729598] ? do_try_to_free_pages+0x2d7/0x360
[ 25.729598] ? security_capable_noaudit+0x45/0x60
[ 25.729598] oom_kill_process+0x219/0x3e0
[ 25.729598] out_of_memory+0x11d/0x480
[ 25.729598] __alloc_pages_slowpath+0xc84/0xd40
[ 25.729598] __alloc_pages_nodemask+0x245/0x260
[ 25.729598] alloc_pages_vma+0xa2/0x270
[ 25.729598] __handle_mm_fault+0xca9/0x10c0
[ 25.729598] handle_mm_fault+0xf3/0x210
[ 25.729598] __do_page_fault+0x240/0x4e0
[ 25.729598] trace_do_page_fault+0x37/0xe0
[ 25.729598] do_async_page_fault+0x19/0x70
[ 25.729598] async_page_fault+0x28/0x30
which leads to VM_FAULT_OOM and so to another out_of_memory when bailing
out from the #PF
[ 25.817589] allocate invoked oom-killer: gfp_mask=0x0(), nodemask=(null), order=0, oom_score_adj=0
[ 25.818821] allocate cpuset=/ mems_allowed=0
[ 25.819259] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.819847] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.820549] Call Trace:
[ 25.820733] dump_stack+0x63/0x82
[ 25.820961] dump_header+0x97/0x21a
[ 25.820961] ? security_capable_noaudit+0x45/0x60
[ 25.820961] oom_kill_process+0x219/0x3e0
[ 25.820961] out_of_memory+0x11d/0x480
[ 25.820961] pagefault_out_of_memory+0x68/0x80
[ 25.820961] mm_fault_error+0x8f/0x190
[ 25.820961] ? handle_mm_fault+0xf3/0x210
[ 25.820961] __do_page_fault+0x4b2/0x4e0
[ 25.820961] trace_do_page_fault+0x37/0xe0
[ 25.820961] do_async_page_fault+0x19/0x70
[ 25.820961] async_page_fault+0x28/0x30
We wouldn't choose another task normally because oom_evaluate_task will
skip selecting another task while there is an existing oom victim but we
can race with the oom_reaper which can set MMF_OOM_SKIP and so select
another task. Tetsuo Handa has pointed out that 9a67f6488eca926f ("mm:
consolidate GFP_NOFAIL checks in the allocator slowpath") made this more
probable because prior to this patch we have retried the allocation with
access to memory reserves which is likely to succeed.
Make sure we at least attempted to allocate with no watermarks before
bailing out and failing the allocation.
Reported-by: Roman Gushchin <guro@fb.com>
Suggested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: 9a67f6488eca926f ("mm: consolidate GFP_NOFAIL checks in the allocator slowpath")
Cc: stable # 4.11+
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a26e19c3e1ff..db8017cd13bb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3873,7 +3873,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
goto got_pg;
/* Avoid allocations with no watermarks from looping endlessly */
- if (test_thread_flag(TIF_MEMDIE))
+ if (alloc_flags == ALLOC_NO_WATERMARKS && test_thread_flag(TIF_MEMDIE))
goto nopage;
/* Retry as long as the OOM killer is making progress */
--
2.11.0
--
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>
^ permalink raw reply related
* [PATCH 0/2] fix premature OOM killer
From: Michal Hocko @ 2017-05-19 11:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Johannes Weiner, Roman Gushchin, Tetsuo Handa, Vladimir Davydov,
linux-mm, LKML
Hi,
this is a follow up for [1]. The first patch is what Tetsuo suggested
[2], I've just added a changelog for it. This one should be merged
as soon as possible. The second patch is still an RFC. I _believe_
that it is the right thing to do but I haven't checked all the PF paths
which return VM_FAULT_OOM to be sure that there is nobody who would return
this error when not doing a real allocation.
[1] http://lkml.kernel.org/r/1495034780-9520-1-git-send-email-guro@fb.com
[2] http://lkml.kernel.org/r/201705182257.HJJ52185.OQStFLFMHVOJOF@I-love.SAKURA.ne.jp
--
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>
^ permalink raw reply
* RE: [PATCH v6 05/15] lockdep: Implement crossrelease feature
From: Byungchul Park @ 2017-05-19 10:56 UTC (permalink / raw)
To: 'Peter Zijlstra'
Cc: mingo, tglx, walken, boqun.feng, kirill, linux-kernel, linux-mm,
iamjoonsoo.kim, akpm, willy, npiggin, kernel-team
In-Reply-To: <20170519103025.zb5impbsek77ahwa@hirez.programming.kicks-ass.net>
> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@infradead.org]
> Sent: Friday, May 19, 2017 7:30 PM
> To: Byungchul Park
> Cc: mingo@kernel.org; tglx@linutronix.de; walken@google.com;
> boqun.feng@gmail.com; kirill@shutemov.name; linux-kernel@vger.kernel.org;
> linux-mm@kvack.org; iamjoonsoo.kim@lge.com; akpm@linux-foundation.org;
> willy@infradead.org; npiggin@gmail.com; kernel-team@lge.com
> Subject: Re: [PATCH v6 05/15] lockdep: Implement crossrelease feature
>
> On Fri, May 19, 2017 at 05:07:08PM +0900, Byungchul Park wrote:
> > On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > > Lockdep is a runtime locking correctness validator that detects and
> > > reports a deadlock or its possibility by checking dependencies between
> > > locks. It's useful since it does not report just an actual deadlock
> but
> > > also the possibility of a deadlock that has not actually happened yet.
> > > That enables problems to be fixed before they affect real systems.
> > >
> > > However, this facility is only applicable to typical locks, such as
> > > spinlocks and mutexes, which are normally released within the context
> in
> > > which they were acquired. However, synchronization primitives like
> page
> > > locks or completions, which are allowed to be released in any context,
> > > also create dependencies and can cause a deadlock. So lockdep should
> > > track these locks to do a better job. The 'crossrelease'
> implementation
> > > makes these primitives also be tracked.
> >
> > Excuse me but I have a question...
> >
> > Only for maskable irq, can I assume that hardirq are prevented within
> > hardirq context? I remember that nested interrupts were allowed in the
> > past but not recommanded. But what about now? I'm curious about the
> > overall direction of kernel and current status. It would be very
> > appriciated if you answer it.
>
> So you're right. In general enabling IRQs from hardirq context is
> discouraged but allowed. However, if you were to do that with a lock
> held that would instantly make lockdep report a deadlock, as the lock is
> then both used from IRQ context and has IRQs enabled.
>
> So from a locking perspective you can assume no nesting, but from a
> state tracking pov we have to deal with the nesting I think (although it
> is very rare).
Got it. Thank you.
> You're asking this in relation to the rollback thing, right? I think we
Exactly. I wanted to make it clear when implementing the rollback for
irqs and works of workqueue.
> should only save the state when hardirq_context goes from 0->1 and
> restore on 1->0.
Yes, it's already done in v6, as you are saying.
Thank you very much.
--
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>
^ permalink raw reply
* Re: RFC v2: post-init-read-only protection for data allocated dynamically
From: Igor Stoppa @ 2017-05-19 10:51 UTC (permalink / raw)
To: Dave Hansen, Michal Hocko, Laura Abbott
Cc: linux-mm, linux-kernel, kernel-hardening@lists.openwall.com
In-Reply-To: <b780ac13-4fc3-ac07-f0c0-7a6cc8dae694@intel.com>
Hello,
On 10/05/17 18:45, Dave Hansen wrote:
> On 05/10/2017 08:19 AM, Igor Stoppa wrote:
>> So I'd like to play a little what-if scenario:
>> what if I was to support exclusively virtual memory and convert to it
>> everything that might need sealing?
>
> Because of the issues related to fracturing large pages, you might have
> had to go this route eventually anyway. Changing the kernel linear map
> isn't nice.
>
> FWIW, you could test this scheme by just converting all the users to
> vmalloc() and seeing what breaks. They'd all end up rounding up all
> their allocations to PAGE_SIZE, but that'd be fine for testing.
Apologies for the long hiatus, it took me some time to figure out
a solution that could somehow address all the comments I got till this
point.
It's here [1], I preferred to start one new thread, since the proposal
has in practice changed significantly, even if in spirit it's still the
same.
It should also take care of the potential waste of space you mentioned
wrt the round up to PAGE_SIZE.
> Could you point out 5 or 10 places in the kernel that you want to convert?
Right now I can only repeat what I said initially:
- the linked list used to implement LSM hooks
- SE linux structures used to implement the policy DB, it should be
about 5 data types
Next week, I'll address the 2 cases I listed, then I'll look for more,
but I think it should not be difficult to find customers for this.
BTW, I forgot to mention that I tested the code against both SLAB and
SLUB and it seems to work fine.
So far I've used QEMU x86-64 as test environment.
--
igor
[1] https://marc.info/?l=linux-mm&m=149519044015956&w=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>
^ permalink raw reply
* Re: [PATCH] mm: per-cgroup memory reclaim stats
From: Michal Hocko @ 2017-05-19 10:47 UTC (permalink / raw)
To: Roman Gushchin
Cc: Johannes Weiner, Tejun Heo, Li Zefan, Vladimir Davydov, cgroups,
linux-doc, linux-kernel, linux-mm
In-Reply-To: <1494530183-30808-1-git-send-email-guro@fb.com>
On Thu 11-05-17 20:16:23, Roman Gushchin wrote:
> Track the following reclaim counters for every memory cgroup:
> PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and
> PGLAZYFREED.
>
> These values are exposed using the memory.stats interface of cgroup v2.
>
> The meaning of each value is the same as for global counters,
> available using /proc/vmstat.
>
> Also, for consistency, rename mem_cgroup_count_vm_event() to
> count_memcg_event_mm().
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Li Zefan <lizefan@huawei.com>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
> Cc: cgroups@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mm@kvack.org
Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> ---
> Documentation/cgroup-v2.txt | 28 ++++++++++++++++++++++++++
> fs/dax.c | 2 +-
> fs/ncpfs/mmap.c | 2 +-
> include/linux/memcontrol.h | 48 ++++++++++++++++++++++++++++++++++++++++++---
> mm/filemap.c | 2 +-
> mm/memcontrol.c | 10 ++++++++++
> mm/memory.c | 4 ++--
> mm/shmem.c | 3 +--
> mm/swap.c | 1 +
> mm/vmscan.c | 30 +++++++++++++++++++++-------
> 10 files changed, 113 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index e50b95c..5804355 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -918,6 +918,34 @@ PAGE_SIZE multiple when read back.
>
> Number of major page faults incurred
>
> + pgrefill
> +
> + Amount of scanned pages (in an active LRU list)
> +
> + pgscan
> +
> + Amount of scanned pages (in an inactive LRU list)
> +
> + pgsteal
> +
> + Amount of reclaimed pages
> +
> + pgactivate
> +
> + Amount of pages moved to the active LRU list
> +
> + pgdeactivate
> +
> + Amount of pages moved to the inactive LRU lis
> +
> + pglazyfree
> +
> + Amount of pages postponed to be freed under memory pressure
> +
> + pglazyfreed
> +
> + Amount of reclaimed lazyfree pages
> +
> memory.swap.current
>
> A read-only single value file which exists on non-root
> diff --git a/fs/dax.c b/fs/dax.c
> index 66d7906..9aac521d 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1230,7 +1230,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> case IOMAP_MAPPED:
> if (iomap.flags & IOMAP_F_NEW) {
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> major = VM_FAULT_MAJOR;
> }
> error = dax_insert_mapping(mapping, iomap.bdev, iomap.dax_dev,
> diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c
> index 0c3905e..6719c0b 100644
> --- a/fs/ncpfs/mmap.c
> +++ b/fs/ncpfs/mmap.c
> @@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_fault *vmf)
> * -- nyc
> */
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> return VM_FAULT_MAJOR;
> }
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 899949b..b2a5b1c 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -357,6 +357,17 @@ static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg)
> }
> struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
>
> +static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
> +{
> + struct mem_cgroup_per_node *mz;
> +
> + if (mem_cgroup_disabled())
> + return NULL;
> +
> + mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
> + return mz->memcg;
> +}
> +
> /**
> * parent_mem_cgroup - find the accounting parent of a memcg
> * @memcg: memcg whose parent to find
> @@ -546,8 +557,23 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order,
> gfp_t gfp_mask,
> unsigned long *total_scanned);
>
> -static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
> - enum vm_event_item idx)
> +static inline void count_memcg_events(struct mem_cgroup *memcg,
> + enum vm_event_item idx,
> + unsigned long count)
> +{
> + if (!mem_cgroup_disabled())
> + this_cpu_add(memcg->stat->events[idx], count);
> +}
> +
> +static inline void count_memcg_page_event(struct page *page,
> + enum memcg_stat_item idx)
> +{
> + if (page->mem_cgroup)
> + count_memcg_events(page->mem_cgroup, idx, 1);
> +}
> +
> +static inline void count_memcg_event_mm(struct mm_struct *mm,
> + enum vm_event_item idx)
> {
> struct mem_cgroup *memcg;
>
> @@ -675,6 +701,11 @@ static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short id)
> return NULL;
> }
>
> +static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
> +{
> + return NULL;
> +}
> +
> static inline bool mem_cgroup_online(struct mem_cgroup *memcg)
> {
> return true;
> @@ -789,8 +820,19 @@ static inline void mem_cgroup_split_huge_fixup(struct page *head)
> {
> }
>
> +static inline void count_memcg_events(struct mem_cgroup *memcg,
> + enum vm_event_item idx,
> + unsigned long count)
> +{
> +}
> +
> +static inline void count_memcg_page_event(struct page *page,
> + enum memcg_stat_item idx)
> +{
> +}
> +
> static inline
> -void mem_cgroup_count_vm_event(struct mm_struct *mm, enum vm_event_item idx)
> +void count_memcg_event_mm(struct mm_struct *mm, enum vm_event_item idx)
> {
> }
> #endif /* CONFIG_MEMCG */
> diff --git a/mm/filemap.c b/mm/filemap.c
> index b7b973b..d640613 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2226,7 +2226,7 @@ int filemap_fault(struct vm_fault *vmf)
> /* No page in the page cache at all */
> do_sync_mmap_readahead(vmf->vma, ra, file, offset);
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> ret = VM_FAULT_MAJOR;
> retry_find:
> page = find_get_page(mapping, offset);
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ff73899..0cfa0aa 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5231,6 +5231,16 @@ static int memory_stat_show(struct seq_file *m, void *v)
> seq_printf(m, "pgfault %lu\n", events[PGFAULT]);
> seq_printf(m, "pgmajfault %lu\n", events[PGMAJFAULT]);
>
> + seq_printf(m, "pgrefill %lu\n", events[PGREFILL]);
> + seq_printf(m, "pgscan %lu\n", events[PGSCAN_KSWAPD] +
> + events[PGSCAN_DIRECT]);
> + seq_printf(m, "pgsteal %lu\n", events[PGSTEAL_KSWAPD] +
> + events[PGSTEAL_DIRECT]);
> + seq_printf(m, "pgactivate %lu\n", events[PGACTIVATE]);
> + seq_printf(m, "pgdeactivate %lu\n", events[PGDEACTIVATE]);
> + seq_printf(m, "pglazyfree %lu\n", events[PGLAZYFREE]);
> + seq_printf(m, "pglazyfreed %lu\n", events[PGLAZYFREED]);
> +
> seq_printf(m, "workingset_refault %lu\n",
> stat[WORKINGSET_REFAULT]);
> seq_printf(m, "workingset_activate %lu\n",
> diff --git a/mm/memory.c b/mm/memory.c
> index 6ff5d72..5aa1348 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2719,7 +2719,7 @@ int do_swap_page(struct vm_fault *vmf)
> /* Had to read the page from swap area: Major fault */
> ret = VM_FAULT_MAJOR;
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vma->vm_mm, PGMAJFAULT);
> } else if (PageHWPoison(page)) {
> /*
> * hwpoisoned dirty swapcache pages are kept for killing
> @@ -3855,7 +3855,7 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> __set_current_state(TASK_RUNNING);
>
> count_vm_event(PGFAULT);
> - mem_cgroup_count_vm_event(vma->vm_mm, PGFAULT);
> + count_memcg_event_mm(vma->vm_mm, PGFAULT);
>
> /* do counter updates before entering really critical section. */
> check_sync_rss_stat(current);
> diff --git a/mm/shmem.c b/mm/shmem.c
> index e67d6ba..8cf16fb 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1645,8 +1645,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
> if (fault_type) {
> *fault_type |= VM_FAULT_MAJOR;
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(charge_mm,
> - PGMAJFAULT);
> + count_memcg_event_mm(charge_mm, PGMAJFAULT);
> }
> /* Here we actually start the io */
> page = shmem_swapin(swap, gfp, info, index);
> diff --git a/mm/swap.c b/mm/swap.c
> index 98d08b4..4f44dbd 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -591,6 +591,7 @@ static void lru_lazyfree_fn(struct page *page, struct lruvec *lruvec,
> add_page_to_lru_list(page, lruvec, LRU_INACTIVE_FILE);
>
> __count_vm_events(PGLAZYFREE, hpage_nr_pages(page));
> + count_memcg_page_event(page, PGLAZYFREE);
> update_page_reclaim_stat(lruvec, 1, 0);
> }
> }
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 5ebf468..76e98b5 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1266,6 +1266,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> }
>
> count_vm_event(PGLAZYFREED);
> + count_memcg_page_event(page, PGLAZYFREED);
> } else if (!mapping || !__remove_mapping(mapping, page, true))
> goto keep_locked;
> /*
> @@ -1295,6 +1296,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> if (!PageMlocked(page)) {
> SetPageActive(page);
> pgactivate++;
> + count_memcg_page_event(page, PGACTIVATE);
> }
> keep_locked:
> unlock_page(page);
> @@ -1725,11 +1727,16 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
> __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken);
> reclaim_stat->recent_scanned[file] += nr_taken;
>
> - if (global_reclaim(sc)) {
> - if (current_is_kswapd())
> + if (current_is_kswapd()) {
> + if (global_reclaim(sc))
> __count_vm_events(PGSCAN_KSWAPD, nr_scanned);
> - else
> + count_memcg_events(lruvec_memcg(lruvec), PGSCAN_KSWAPD,
> + nr_scanned);
> + } else {
> + if (global_reclaim(sc))
> __count_vm_events(PGSCAN_DIRECT, nr_scanned);
> + count_memcg_events(lruvec_memcg(lruvec), PGSCAN_DIRECT,
> + nr_scanned);
> }
> spin_unlock_irq(&pgdat->lru_lock);
>
> @@ -1741,11 +1748,16 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
>
> spin_lock_irq(&pgdat->lru_lock);
>
> - if (global_reclaim(sc)) {
> - if (current_is_kswapd())
> + if (current_is_kswapd()) {
> + if (global_reclaim(sc))
> __count_vm_events(PGSTEAL_KSWAPD, nr_reclaimed);
> - else
> + count_memcg_events(lruvec_memcg(lruvec), PGSTEAL_KSWAPD,
> + nr_reclaimed);
> + } else {
> + if (global_reclaim(sc))
> __count_vm_events(PGSTEAL_DIRECT, nr_reclaimed);
> + count_memcg_events(lruvec_memcg(lruvec), PGSTEAL_DIRECT,
> + nr_reclaimed);
> }
>
> putback_inactive_pages(lruvec, &page_list);
> @@ -1890,8 +1902,11 @@ static unsigned move_active_pages_to_lru(struct lruvec *lruvec,
> }
> }
>
> - if (!is_active_lru(lru))
> + if (!is_active_lru(lru)) {
> __count_vm_events(PGDEACTIVATE, nr_moved);
> + count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE,
> + nr_moved);
> + }
>
> return nr_moved;
> }
> @@ -1929,6 +1944,7 @@ static void shrink_active_list(unsigned long nr_to_scan,
> reclaim_stat->recent_scanned[file] += nr_taken;
>
> __count_vm_events(PGREFILL, nr_scanned);
> + count_memcg_events(lruvec_memcg(lruvec), PGREFILL, nr_scanned);
>
> spin_unlock_irq(&pgdat->lru_lock);
>
> --
> 2.7.4
>
> --
> 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>
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox