On 4/28/20 11:48 PM, David Rientjes wrote:
> On Tue, 28 Apr 2020, Vlastimil Babka wrote:
>
> Yes, order-0 reclaim capture is interesting since the issue being reported
> here is userspace going out to lunch because it loops for an unbounded
> amount of time trying to get above a
On 4/27/20 10:30 PM, Andrew Morton wrote:
On Sun, 26 Apr 2020 20:12:58 -0700 (PDT) David Rientjes
wrote:
GFP_ATOMIC allocators can access below these per-zone watermarks. So the
issue is that per-zone free pages stays between ALLOC_HIGH watermarks
(the watermark that GFP_ATOMIC
On 4/27/20 8:33 PM, Andrew Morton wrote:
On Mon, 27 Apr 2020 20:04:29 +0200 Vlastimil Babka wrote:
...
+ sysctl.*= [KNL]
+ Set a sysctl parameter, right before loading the init
+ process, as if the value was written to the respective
On 10/23/19 4:31 PM, Michal Hocko wrote:
> On Wed 23-10-19 15:48:36, Vlastimil Babka wrote:
>> On 10/23/19 3:37 PM, Michal Hocko wrote:
>>>
>>> But those wouldn't really help to prevent from the lockup, right?
>>
>> No, but it would perhaps hel
+ linux-api
On 10/23/19 12:27 PM, Michal Hocko wrote:
> From: Michal Hocko
>
> pagetypeinfo_showfree_print is called by zone->lock held in irq mode.
> This is not really nice because it blocks both any interrupts on that
> cpu and the page allocator. On large machines this might even trigger
>
+ linux-api
On 10/23/19 12:27 PM, Michal Hocko wrote:
> From: Michal Hocko
>
> /proc/pagetypeinfo is a debugging tool to examine internal page
> allocator state wrt to fragmentation. It is not very useful for
> any other use so normal users really do not need to read this file.
>
> Waiman Long
On 10/23/19 3:37 PM, Michal Hocko wrote:
> On Wed 23-10-19 15:32:05, Vlastimil Babka wrote:
>> On 10/23/19 12:27 PM, Michal Hocko wrote:
>>> From: Michal Hocko
>>>
>>> pagetypeinfo_showfree_print is called by zone->lock held in irq mode.
>>> Th
0 N0=49664 N1=52736
kernelpagesize_kB=4
The THP utilization is now back at 100% as 5.3 (modulo mis-alignment of
the mem_eater area). This is expected, as the second try that's not limited
to __GFP_THISNODE is also not limited by the newly introduced (in 5.4)
heuristics
that checks COMPACT_SKIPPE
On 10/17/19 12:53 AM, Fengguang Wu wrote:
> This avoids duplicated PageReferenced() calls.
> No behavior change.
>
> Signed-off-by: Fengguang Wu
Acked-by: Vlastimil Babka
> ---
> mm/swap.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
&g
t; Signed-off-by: Mel Gorman
> Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
ch: 1
> 768 batch: 63
> 256 high: 0
> 768 high: 378
>
> Cc: sta...@vger.kernel.org # v4.1+
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
> ---
> mm/page_alloc.c | 8
> 1 file changed,
On 10/21/19 11:48 AM, Mel Gorman wrote:
> Memory hotplug needs to be able to reset and reinit the pcpu allocator
> batch and high limits but this action is internal to the VM. Move
> the declaration to internal.h
>
> Signed-off-by: Mel Gorman
> Acked-by: Michal Hocko
Acked-by: Vlastimil Babka
On 10/14/19 11:12 AM, Michal Hocko wrote:
>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> index 4ae967b..a23509f 100644
>> --- a/mm/mempolicy.c
>> +++ b/mm/mempolicy.c
>> @@ -1328,9 +1328,11 @@ static int get_nodes(nodemask_t *nodes, const
>> unsigned long __user *nmask,
>> unsigned long
gt;
> Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to
> zones until online") # visible after d0dc12e86b319
> Signed-off-by: Qian Cai
> Cc: Andrew Morton
> Cc: Vlastimil Babka
> Cc: Michal Hocko
> Cc: Thomas Gleixner
> Cc: "P
ains a full RCU
> barrier. This guarantees that all scheduled page release RCU works
> will complete before the memcg pointer will be zeroed.
>
> Big thanks for Karsten for the perfect report containing all necessary
> information, his help with the analysis of the problem and testi
On 10/9/19 2:44 AM, Ajay Kaher wrote:
> From: Linus Torvalds
>
> commit 8fde12ca79aff9b5ba951fce1a2641901b8d8e64 upstream.
>
> If the page refcount wraps around past zero, it will be freed while
> there are still four billion references to it. One of the possible
> avenues for an attacker to
"mm/compaction.c: correct zone boundary handling when
resetting pageblock skip hints")
Cc:
Signed-off-by: Vlastimil Babka
---
mm/compaction.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index ce08b39d85d4..672d3c78c6ab 10
d-off-by: Michal Hocko
I still believe that using __GFP_NORETRY as needed is a cleaner solution
than a check for pageblock order and __GFP_IO, but that can be always
changed later. This patch does fix the hugetlbfs regression, so
Acked-by: Vlastimil Babka
On 10/5/19 12:11 AM, Roman Gushchin wrote:
>
> One possible approach to this problem is to switch inodes associated
> with dying wbs to the root wb. Switching is a best effort operation
> which can fail silently, so unfortunately we can't run once over a
> list of associated inodes (even if we'd
On 10/2/19 10:43 AM, Michal Hocko wrote:
> On Wed 02-10-19 06:16:43, Yang Shi wrote:
>> The commit 87eaceb3faa59b9b4d940ec9554ce251325d83fe ("mm: thp: make
>> deferred split shrinker memcg aware") makes deferred split queue per
>> memcg to resolve memcg pre-mature OOM problem. But, all nodes end
term for a page".
Suggested-by: Kirill A. Shutemov
Signed-off-by: Vlastimil Babka
---
include/linux/page_ext.h | 2 +-
mm/page_owner.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index 5e8565
/20190911083921.4158-1-walter-zh...@mediatek.com/
[3] https://lore.kernel.org/linux-mm/20190930122916.14969-1-vba...@suse.cz/
Vlastimil Babka (3):
mm, page_owner: fix off-by-one error in __set_page_owner_handle()
mm, page_owner: decouple freeing stack trace from debug_pagealloc
mm, page_owner: rename flag
introduce a page_ext_next() inline
function for that.
Reported-by: Kirill A. Shutemov
Fixes: 7e2f2a0cd17c ("mm, page_owner: record page owner for each subpage")
Signed-off-by: Vlastimil Babka
Acked-by: Kirill A. Shutemov
---
include/linux/page_ext.h | 8
mm/page_e
e improved error reports.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
Suggested-by: Dmitry Vyukov
Suggested-by: Walter Wu
Suggested-by: Andrey Ryabinin
Suggested-by: Kirill A. Shutemov
Suggested-by: Qian Cai
Signed-off-by: Vlastimil Babka
---
Documentation/dev-tools/kasan.rst |
+ 0
> ...
> page_ext = lookup_page_ext(page + i); <- lookup_page_ext(page + 0)
> }
>
> Cc: Andrew Morton
> Cc: Vlastimil Babka
> Cc: Michal Hocko
> Signed-off-by: Miles Chen
> Fixes: 7e2f2a0cd17c ("mm, page_owner: record page owner for each subpag
On 10/3/19 1:03 AM, David Rientjes wrote:
> Hugetlb allocations use __GFP_RETRY_MAYFAIL to aggressively attempt to get
> hugepages that the user needs. Commit b39d0ee2632d ("mm, page_alloc:
> avoid expensive reclaim when compaction may not succeed") intends to
> improve allocator behind for
On 10/3/19 12:32 AM, David Rientjes wrote:
> On Wed, 2 Oct 2019, Michal Hocko wrote:
>
If
hugetlb wants to stress this to the fullest extent possible, it already
appropriately uses __GFP_RETRY_MAYFAIL.
>>>
>>> Which doesn't work anymore right now, and should again after this
On 10/1/19 10:31 PM, David Rientjes wrote:
> On Tue, 1 Oct 2019, Vlastimil Babka wrote:
>
>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> index 4ae967bcf954..2c48146f3ee2 100644
>> --- a/mm/mempolicy.c
>> +++ b/mm/mempolicy.c
>> @@ -2129,18 +2129,20 @@
On 10/1/19 3:18 PM, Qian Cai wrote:
> On Tue, 2019-10-01 at 14:35 +0200, Vlastimil Babka wrote:
>> On 10/1/19 2:32 PM, Vlastimil Babka wrote:
>>
>> Or suggest how to replace page_owner=on with something else
>> (page_owner=full?)
>> and I can change that. But I
If anything the __GFP_RETRY_MAYFAIL needs to be reflected in the
> code.
Yeah it's roughly what I expected, thanks for the testing. How about this
patch on top?
---8<---
>From 3ae67ab2274626c276ff2dd58794215a8461f045 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka
Date: Tue, 1 Oct 2019 14:20:58 +0200
S
On 10/1/19 2:32 PM, Vlastimil Babka wrote:
> On 10/1/19 2:26 PM, Qian Cai wrote:
>> On Tue, 2019-10-01 at 14:51 +0300, Kirill A. Shutemov wrote:
>>> On Tue, Oct 01, 2019 at 10:07:44AM +0200, Vlastimil Babka wrote:
>>>> On 10/1/19 1:49 AM, Qian Cai wrote:
>&g
On 10/1/19 2:26 PM, Qian Cai wrote:
> On Tue, 2019-10-01 at 14:51 +0300, Kirill A. Shutemov wrote:
>> On Tue, Oct 01, 2019 at 10:07:44AM +0200, Vlastimil Babka wrote:
>>> On 10/1/19 1:49 AM, Qian Cai wrote:
>>
>> DEBUG_PAGEALLOC is much more intrusive debug option. No
On 10/1/19 1:49 AM, Qian Cai wrote:
>
>
>> On Sep 30, 2019, at 5:43 PM, Vlastimil Babka wrote:
>>
>> Well, my use case is shipping production kernels with CONFIG_PAGE_OWNER
>> and CONFIG_DEBUG_PAGEALLOC enabled, and instructing users to boot-time
>> ena
On 9/30/19 2:49 PM, Qian Cai wrote:
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3237,6 +3237,14 @@
>> we can turn it on.
>> on: enable the feature
>>
>> +page_owner_free=
>>
On 9/30/19 2:29 PM, Vlastimil Babka wrote:
> Commit 37389167a281 ("mm, page_owner: keep owner info when freeing the page")
> has introduced a flag PAGE_EXT_OWNER_ACTIVE to indicate that page is tracked
> as
> being allocated. Kirril suggested naming it PAGE_EXT_O
term for a page".
Suggested-by: Kirill A. Shutemov
Signed-off-by: Vlastimil Babka
---
include/linux/page_ext.h | 2 +-
mm/page_owner.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index 5e8565
] https://lore.kernel.org/linux-mm/20190820131828.22684-1-vba...@suse.cz/
[2]
https://lore.kernel.org/linux-arm-kernel/20190911083921.4158-1-walter-zh...@mediatek.com/
[3] https://lore.kernel.org/r/20190925143056.25853-1-vbabka%40suse.cz
Vlastimil Babka (3):
mm, page_owner: fix off-by-one error
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
Suggested-by: Dmitry Vyukov
Suggested-by: Walter Wu
Suggested-by: Andrey Ryabinin
Suggested-by: Kirill A. Shutemov
Signed-off-by: Vlastimil Babka
---
.../admin-guide/kernel-parameters.txt | 8 ++
Documentation/dev-tools
introduce a page_ext_next() inline
function for that.
Reported-by: Kirill A. Shutemov
Fixes: 7e2f2a0cd17c ("mm, page_owner: record page owner for each subpage")
Signed-off-by: Vlastimil Babka
Acked-by: Kirill A. Shutemov
---
include/linux/page_ext.h | 8
mm/page_e
On 9/26/19 11:16 AM, Kirill A. Shutemov wrote:
> On Wed, Sep 25, 2019 at 04:30:51PM +0200, Vlastimil Babka wrote:
>> The commit 8974558f49a6 ("mm, page_owner, debug_pagealloc: save and dump
>> freeing stack trace") enhanced page_owner to also store freeing stack trace
On 9/26/19 11:18 AM, Kirill A. Shutemov wrote:
> On Wed, Sep 25, 2019 at 04:30:52PM +0200, Vlastimil Babka wrote:
>> Commit 37389167a281 ("mm, page_owner: keep owner info when freeing the page")
>> has introduced a flag PAGE_EXT_OWNER_ACTIVE to indicate that page i
...@suse.cz/
[2]
https://lore.kernel.org/linux-arm-kernel/20190911083921.4158-1-walter-zh...@mediatek.com/
Vlastimil Babka (3):
mm, page_owner: fix off-by-one error in __set_page_owner_handle()
mm, debug, kasan: save and dump freeing stack trace for kasan
mm, page_owner: rename flag indicating
term for a page".
Suggested-by: Kirill A. Shutemov
Signed-off-by: Vlastimil Babka
---
include/linux/page_ext.h | 2 +-
mm/page_owner.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index 5e8565
introduce a page_ext_next() inline
function for that.
Reported-by: Kirill A. Shutemov
Fixes: 7e2f2a0cd17c ("mm, page_owner: record page owner for each subpage")
Signed-off-by: Vlastimil Babka
---
include/linux/page_ext.h | 8
mm/page_ext.c| 23 +---
er=on.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
Suggested-by: Dmitry Vyukov
Suggested-by: Walter Wu
Suggested-by: Andrey Ryabinin
Signed-off-by: Vlastimil Babka
Reviewed-by: Andrey Ryabinin
---
Documentation/dev-tools/kasan.rst | 4
mm/Kconfig.debug |
introduce a page_ext_next() inline
function for that.
Reported-by: Kirill A. Shutemov
Fixes: 7e2f2a0cd17c ("mm, page_owner: record page owner for each subpage")
Signed-off-by: Vlastimil Babka
---
include/linux/page_ext.h | 8
mm/page_ext.c| 23 +---
er=on.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
Suggested-by: Dmitry Vyukov
Suggested-by: Walter Wu
Suggested-by: Andrey Ryabinin
Signed-off-by: Vlastimil Babka
Reviewed-by: Andrey Ryabinin
---
Documentation/dev-tools/kasan.rst | 4
mm/Kconfig.debug |
...@suse.cz/
[2]
https://lore.kernel.org/linux-arm-kernel/20190911083921.4158-1-walter-zh...@mediatek.com/
Vlastimil Babka (3):
mm, page_owner: fix off-by-one error in __set_page_owner_handle()
mm, debug, kasan: save and dump freeing stack trace for kasan
mm, page_owner: rename flag indicating
term for a page".
Suggested-by: Kirill A. Shutemov
Signed-off-by: Vlastimil Babka
---
include/linux/page_ext.h | 2 +-
mm/page_owner.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index 5e8565
On 9/24/19 1:42 PM, Kirill A. Shutemov wrote:
>> --- a/mm/page_owner.c
>> +++ b/mm/page_owner.c
>> @@ -24,6 +24,9 @@ struct page_owner {
>> short last_migrate_reason;
>> gfp_t gfp_mask;
>> depot_stack_handle_t handle;
>> +#ifdef CONFIG_DEBUG_PAGEALLOC
>> +depot_stack_handle_t
On 9/24/19 1:31 PM, Kirill A. Shutemov wrote:
> On Tue, Aug 20, 2019 at 03:18:26PM +0200, Vlastimil Babka wrote:
>> Currently, page owner info is only recorded for the first page of a
>> high-order
>> allocation, and copied to tail pages in the event of a split page. Wit
On 9/20/19 1:37 AM, Nitin Gupta wrote:
> On Tue, 2019-08-20 at 10:46 +0200, Vlastimil Babka wrote:
>>
>> That's a lot of control knobs - how is an admin supposed to tune them to
>> their
>> needs?
>
>
> Yes, it's difficult for an admin to get so many tun
On 9/19/19 8:26 PM, Ben Hutchings wrote:
On Mon, 2019-08-19 at 18:58 +0100, Vlastimil Babka wrote:
[...]
Hi, I'm sending this stable-only patch for consideration because it's probably
unrealistic to backport the 4.13 switch to generic GUP. I can look at 4.4 and
3.16 if accepted. The RCU page
C_ENABLE_DEFAULT=y should also work correctly.
OK.
8<
>From 7437c43f02682fdde5680fa83e87029f7529e222 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka
Date: Mon, 16 Sep 2019 11:28:19 +0200
Subject: [PATCH] mm, debug, kasan: save and dump freeing stack trace for kasan
The commit &q
On 9/17/19 5:53 PM, Vitaly Wool wrote:
> Currently there is a leak in init_z3fold_page() -- it allocates
> handles from kmem cache even for headless pages, but then they are
> never used and never freed, so eventually kmem cache may get
> exhausted. This patch provides a fix for that.
>
>
On 9/16/19 5:57 PM, Andrey Ryabinin wrote:
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -710,8 +710,12 @@ static int __init early_debug_pagealloc(char *buf)
>> if (kstrtobool(buf, ))
>> return -EINVAL;
>>
>> -if (enable)
>> +if (enable) {
>>
On 9/16/19 12:36 PM, Michal Hocko wrote:
> On Fri 13-09-19 12:18:49, Kirill A. Shutemov wrote:
>> Adding fully unmapped pages into deferred split queue is not productive:
>> these pages are about to be freed or they are pinned and cannot be split
>> anyway.
>>
>> Signed-off-by: Kirill A. Shutemov
gzilla.kernel.org/show_bug.cgi?id=203967
8<
>From 887e3c092c073d996098ac2b101b0feaef110b54 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka
Date: Mon, 16 Sep 2019 11:28:19 +0200
Subject: [PATCH] mm, debug, kasan: save and dump freeing stack trace for kasan
The commit "mm, page_owner, debug_pagealloc:
On 9/12/19 4:08 PM, Walter Wu wrote:
extern void __reset_page_owner(struct page *page, unsigned int order);
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 6c9682ce0254..dc560c7562e8 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -41,6 +41,8 @@ config KASAN_GENERIC
lly automatic, how about something
like this (on top of mmotm/next)? If you agree I'll add changelog
and send properly.
8<
>From a528d14c71d7fdf5872ca8ab3bd1b5bad26670c9 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka
Date: Thu, 12 Sep 2019 15:51:23 +0200
Subject: [PATCH] make
On 9/11/19 4:33 PM, Pengfei Li wrote:
In the past two days, I am working on what you suggested.
Great!
So far, I have completed the coding work, but I need some time to make
sure there are no bugs and verify the impact on performance.
It would probably be hard to measure with sufficient
On 9/10/19 12:50 PM, Andrey Ryabinin wrote:
For slab objects we memorize both alloc and free stacks. You'll never know in
advance what information will be usefull
to fix an issue, so it usually better to provide more information. I don't
think we should do anything different for pages.
On 9/10/19 12:31 PM, Vitaly Wool wrote:
With the original commit applied, z3fold_zpool_destroy() may
get blocked on wait_event() for indefinite time. Revert this
commit for the time being to get rid of this problem since the
issue the original commit addresses is less severe.
This reverts
On 9/10/19 3:26 AM, Pengfei Li wrote:
KMALLOC_DMA will be initialized only if KMALLOC_NORMAL with
the same index exists.
And kmalloc_caches[KMALLOC_NORMAL][0] is always NULL.
Therefore, the loop that initializes KMALLOC_DMA should start
at 1 instead of 0, which will reduce 1 meaningless
On 9/9/19 8:30 PM, Rasmus Villemoes wrote:
> On 09/09/2019 18.53, Pengfei Li wrote:
>> On Mon, Sep 9, 2019 at 10:59 PM Vlastimil Babka wrote:
>
>>>> /*
>>>>* kmalloc_info[] is to make slub_debug=,kmalloc-xx option work at boot
>>>> time.
&g
On 9/3/19 6:04 PM, Pengfei Li wrote:
The 'type' of the function new_kmalloc_cache should be
enum kmalloc_cache_type instead of int, so correct it.
OK
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions
On 9/3/19 6:04 PM, Pengfei Li wrote:
The size of kmalloc can be obtained from kmalloc_info[],
so remove kmalloc_size() that will not be used anymore.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
---
include/linux/slab.h | 20
mm/slab.c| 5
On 9/3/19 6:04 PM, Pengfei Li wrote:
Since the name of kmalloc can be obtained from kmalloc_info[],
remove the kmalloc_cache_name() that is no longer used.
That could simply be part of patch 1/5 really.
Signed-off-by: Pengfei Li
Ack
---
mm/slab_common.c | 15 ---
1 file
predefines the names of all types of kmalloc to save
the time spent dynamically generating names.
As I said, IMHO it's more useful that we don't need to allocate the
names dynamically anymore, and it's simpler overall.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
On 9/9/19 10:24 AM, walter-zh...@mediatek.com wrote:
From: Walter Wu
This patch is KASAN report adds the alloc/free stacks for page allocator
in order to help programmer to see memory corruption caused by page.
By default, KASAN doesn't record alloc and free stack for page allocator.
It is
On 9/9/19 10:53 AM, Walter Wu wrote:
KASAN will record last stack of page in order to help programmer
to see memory corruption caused by page.
What is difference between page_owner and our patch?
page_owner records alloc stack of page, but our patch is to record
last stack(it may be alloc or
On 9/8/19 3:50 AM, David Rientjes wrote:
> On Sat, 7 Sep 2019, Linus Torvalds wrote:
>
>>> Andrea acknowledges the swap storm that he reported would be fixed with
>>> the last two patches in this series
>>
>> The problem is that even you aren't arguing that those patches should
>> go into 5.3.
>>
On 8/30/19 11:25 AM, Sangwoo wrote:
> The highatomic migrate block can be increased to 1% of Total memory.
> And, this is for only highorder ( > 0 order). So, this block size is
> excepted during check watermark if allocation type isn't alloc_harder.
>
> It has problem. The usage of highatomic is
On 9/3/19 6:04 PM, Pengfei Li wrote:
> There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
> and KMALLOC_DMA.
>
> The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
> but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
> generated by kmalloc_cache_name().
>
On 9/5/19 11:00 AM, Michal Hocko wrote:
> [Ccing Mike for checking on the hugetlb side of this change]
>
> On Wed 04-09-19 12:54:22, David Rientjes wrote:
>> Memory compaction has a couple significant drawbacks as the allocation
>> order increases, specifically:
>>
>> - isolate_freepages() is
On 9/4/19 4:24 PM, Walter Wu wrote:
> On Wed, 2019-09-04 at 16:13 +0200, Vlastimil Babka wrote:
>> On 9/4/19 4:06 PM, Walter Wu wrote:
>>
>> The THP fix is not required for the rest of the series, it was even merged to
>> mainline separately.
>>
>>>
On 9/5/19 8:18 AM, zhong jiang wrote:
> On 2019/9/5 2:48, Andrew Morton wrote:
> Firstly, I consider the some modified method as you has writen down above.
> It seems to work well.
> According to Vlastimil's feedback, I repost the patch in v2, changing the
> parameter to long to fix
> the
On 9/4/19 9:01 PM, Andrew Morton wrote:
> On Wed, 4 Sep 2019 13:24:58 +0200 Vlastimil Babka wrote:
>
>> On 9/4/19 12:26 PM, zhong jiang wrote:
>>> With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages"'
>>> compare with zero. And __get_user_pag
On 9/4/19 8:48 PM, Andrew Morton wrote:
> On Wed, 4 Sep 2019 13:24:58 +0200 Vlastimil Babka wrote:
>
>> On 9/4/19 12:26 PM, zhong jiang wrote:
>>> With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages"'
>>> compare with zero. And __get_user_pag
On 9/4/19 4:06 PM, Walter Wu wrote:
> On Wed, 2019-09-04 at 14:49 +0200, Vlastimil Babka wrote:
>> On 9/4/19 8:51 AM, Walter Wu wrote:
>> > This patch is KASAN report adds the alloc/free stacks for page allocator
>> > in order to help programmer to see memor
On 9/4/19 8:51 AM, Walter Wu wrote:
> This patch is KASAN report adds the alloc/free stacks for page allocator
> in order to help programmer to see memory corruption caused by page.
>
> By default, KASAN doesn't record alloc/free stack for page allocator.
> It is difficult to fix up page
On 9/4/19 12:26 PM, zhong jiang wrote:
> With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages"'
> compare with zero. And __get_user_pages_locked will return an long value.
> Hence, Convert the long to compare with zero is feasible.
It would be nicer if the parameter nr_pages was
On 8/30/19 5:25 PM, Qian Cai wrote:
> On Fri, 2019-08-30 at 17:11 +0200, Eric Dumazet wrote:
>>
>> On 8/30/19 4:57 PM, Qian Cai wrote:
>>> When running heavy memory pressure workloads, the system is throwing
>>> endless warnings below due to the allocation could fail from
>>> __build_skb(), and
remove_vm_area(area->addr);
>> kfree(area);
>> return NULL;
>> }
>>
>> +area->pages = pages;
>> +
>> for (i = 0; i < area->nr_pages; i++) {
>> struct page *page;
>>
>
On 8/28/19 8:06 AM, Wei Yang wrote:
> When insert and delete a vma, it will compute and propagate related subtree
> gap. After some investigation, we can reduce subtree gap propagation a little.
>
> [1]: This one reduce the propagation by update *next* gap after itself, since
> *next* must
On 8/27/19 1:02 PM, Kirill A. Shutemov wrote:
> On Tue, Aug 27, 2019 at 08:01:39AM +0200, Michal Hocko wrote:
>> On Mon 26-08-19 16:15:38, Kirill A. Shutemov wrote:
>>>
>>> Unmapped completely pages will be freed with current code. Deferred split
>>> only applies to partly mapped THPs: at least on
On 7/20/19 1:32 AM, Ralph Campbell wrote:
> When CONFIG_MIGRATE_VMA_HELPER is enabled, migrate_vma() calls
> migrate_vma_collect() which initializes a struct mm_walk but
> didn't initialize mm_walk.pud_entry. (Found by code inspection)
> Use a C structure initialization to make sure it is set to
actually use page allocator
directly, so no change there).
Ideally SLOB and SLUB would be handled in separate patches, but due to the
shared kmalloc_order() function and different kfree() implementations, it's
easier to patch both at once to prevent inconsistencies.
Signed-off-by: Vlastimil Babka
/c3157c8e8e0e7588312b40c853f65c02fe6c957a.1566399731.git.christophe.le...@c-s.fr/
[2]
https://lore.kernel.org/linux-fsdevel/20190225040904.5557-1-ming@redhat.com/
[3] https://lwn.net/Articles/787740/
Signed-off-by: Vlastimil Babka
---
Documentation/core-api/memory-allocation.rst | 4 ++
include/linux/slab.h
On 8/22/19 3:17 PM, Dave Chinner wrote:
> On Thu, Aug 22, 2019 at 02:19:04PM +0200, Vlastimil Babka wrote:
>> On 8/22/19 2:07 PM, Dave Chinner wrote:
>> > On Thu, Aug 22, 2019 at 01:14:30PM +0200, Vlastimil Babka wrote:
>> >
>> > No, the problem is t
ore calling madvise(MADV_DONTNEED):
>> MemAvailable: 43531960 kB
>> AnonPages: 1096660 kB
>> KReclaimable: 26156 kB
>> AnonHugePages: 1056768 kB
>>
>> After calling madvise(MADV_DONTNEED):
>> MemAvailable: 44411164 kB
>> AnonPages:
On 8/22/19 2:07 PM, Dave Chinner wrote:
> On Thu, Aug 22, 2019 at 01:14:30PM +0200, Vlastimil Babka wrote:
>
> No, the problem is this (using kmalloc as a general term for
> allocation, whether it be kmalloc, kmem_cache_alloc, alloc_page, etc)
>
>some random kernel
On 8/22/19 12:14 PM, Dave Chinner wrote:
> On Thu, Aug 22, 2019 at 11:10:57AM +0200, Peter Zijlstra wrote:
>>
>> Ah, current_gfp_context() already seems to transfer PF_MEMALLOC_NOFS
>> into the GFP flags.
>>
>> So are we sure it is broken and needs mending?
>
> Well, that's what we are trying
4.
SLUB debug tracking additionaly stores cpu, pid and timestamp. This could be
added later, if deemed useful enough to justify the additional page_ext
structure size.
Vlastimil Babka (4):
mm, page_owner: handle THP splits correctly
mm, page_owner: record page owner for each subpage
mm
free pages are irrelevant for the
memory statistics or leak detection that's the typical use case of the file,
anyway.
Signed-off-by: Vlastimil Babka
---
include/linux/page_ext.h | 1 +
mm/page_owner.c | 34 --
2 files changed, 25 insertions(+), 10 deletions(-)
__x64_sys_clone+0x75/0x80
do_syscall_64+0x6e/0x1e0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f10af854a10
...
Signed-off-by: Vlastimil Babka
---
.../admin-guide/kernel-parameters.txt | 2 +
mm/Kconfig.debug | 4 +-
mm/page_owner.c
gh-order allocations are compound pages with true
head and tail pages). When reading the page_owner debugfs file, keep skipping
the "tail" pages so that stats gathered by existing scripts don't get inflated.
Signed-off-by: Vlastimil Babka
---
mm/page_owner.c | 40 --
. This patch
fixes that by adding the split_page_owner() call into __split_huge_page().
Fixes: a9627bc5e34e ("mm/page_owner: introduce split_page_owner and replace
manual handling")
Reported-by: Kirill A. Shutemov
Cc: sta...@vger.kernel.org
Signed-off-by: Vlastimil Babka
---
mm/huge_me
On 8/20/19 4:30 AM, Christoph Hellwig wrote:
> On Mon, Aug 19, 2019 at 07:46:00PM +0200, David Sterba wrote:
>> Another thing that is lost is the slub debugging support for all
>> architectures, because get_zeroed_pages lacking the red zones and sanity
>> checks.
>>
>> I find working with raw
+CC Khalid Aziz who proposed a different approach:
https://lore.kernel.org/linux-mm/20190813014012.30232-1-khalid.a...@oracle.com/T/#u
On 8/16/19 11:43 PM, Nitin Gupta wrote:
> For some applications we need to allocate almost all memory as
> hugepages. However, on a running system, higher order
601 - 700 of 6107 matches
Mail list logo
