On 4/10/19 4:47 AM, Tobin C. Harding wrote:
> Recently a 2 year old bug was found in the SLAB allocator that crashes
> the kernel. This seems to imply that not that many people are using the
> SLAB allocator.
AFAIK that bug required CONFIG_DEBUG_SLAB_LEAK, not just SLAB. That
seems to imply not
On 4/9/19 3:28 PM, Konstantin Khlebnikov wrote:
> On 09.04.2019 16:16, Vlastimil Babka wrote:
>> On 4/9/19 3:01 PM, Konstantin Khlebnikov wrote:
>>> Commit 58bc4c34d249 ("mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly")
>>> depends on skipping vmstat entries
nr_tlb_remote_*" for UP.
Right, that's the the best solution IMHO.
> Fixes: 58bc4c34d249 ("mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly")
> Signed-off-by: Konstantin Khlebnikov
Acked-by: Vlastimil Babka
> ---
> mm/vmstat.c |5 -
> 1 file changed, 5 de
ad of lru
> slab: Use slab_list instead of lru
> mm: Remove stale comment from page struct
For the whole series:
Acked-by: Vlastimil Babka
>
> include/linux/list.h | 18
> include/linux/mm_types.h | 2 +-
> mm/slab.c| 49 +
On 4/3/19 11:13 PM, Tobin C. Harding wrote:
> According to 0day test robot this is triggering an error from
> CHECK_DATA_CORRUPTION when the kernel is built with CONFIG_DEBUG_LIST.
FWIW, that report [1] was for commit 15c8410c67adef from next-20190401. I've
checked and it's still the v4 version,
On 4/4/19 5:57 PM, Christopher Lameter wrote:
> On Thu, 4 Apr 2019, Vlastimil Babka wrote:
>
>> I looked a bit at SLUB debugging capabilities and first thing I noticed is
>> there's no static key guarding the runtime enablement as is common for
>> similar
>> debugg
On 4/3/19 11:40 AM, Oscar Salvador wrote:
> On Wed, Apr 03, 2019 at 10:37:57AM +0200, Michal Hocko wrote:
>> That being said it should be the caller of the hotplug code to tell
>> the vmemmap allocation strategy. For starter, I would only pack vmemmaps
>> for "regular" kernel zone memory. Movable
Some debugging checks in SLUB are not hidden behind kmem_cache_debug() check.
Add the check so that those places can also benefit from reduced overhead
thanks to the the static key added by the previous patch.
Signed-off-by: Vlastimil Babka
---
mm/slub.c | 12 +++-
1 file changed, 11
rently cached. So the advantage of a static key in
slow path __slab_free() should be more useful immediately.
Vlastimil Babka (2):
mm, slub: introduce static key for slub_debug
mm, slub: add missing kmem_cache_debug() checks
mm/slub.c | 31 +--
1 file changed,
.
For now and for simplicity, the static key stays enabled for the whole uptime
once activated for any cache, although some per-cache debugging options can be
also disabled at runtime. This can be improved if there's interest.
Signed-off-by: Vlastimil Babka
---
mm/slub.c | 19 ++-
1
On 4/2/19 11:43 AM, Peng Fan wrote:
> There is no function named munlock_vma_pages, correct it to
> munlock_vma_page.
>
> Signed-off-by: Peng Fan
Acked-by: Vlastimil Babka
> ---
> mm/swap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --
On 3/20/19 1:43 AM, Christopher Lameter wrote:
> On Tue, 19 Mar 2019, Vlastimil Babka wrote:
>
>> The recent thread [1] inspired me to look into guaranteeing alignment for
>> kmalloc() for power-of-two sizes. Turns out it's not difficult and in most
>> configuratio
On 3/15/19 11:11 AM, Pankaj Suryawanshi wrote:
>
> [ cc Aneesh kumar, Anshuman, Hillf, Vlastimil]
Can you send a proper patch with changelog explaining the change? I
don't know the context of this thread.
> From: Pankaj Suryawanshi
> Sent: 15 March 2019 11:35:05
> To: Kirill Tkhai; Michal Hocko
On 3/2/19 5:38 AM, Yafang Shao wrote:
> show the gfp flag names instead of the gfp_mask could make the trace
> more convenient.
>
> Signed-off-by: Yafang Shao
Acked-by: Vlastimil Babka
> ---
> include/trace/events/compaction.h | 4 ++--
> 1 file changed, 2 inser
ret_from_fork+0x10/0x18
>
> Fixes: 70b44595eafe ("mm, compaction: use free lists to quickly locate a
> migration source")
> Acked-by: Mel Gorman
> Signed-off-by: Qian Cai
Acked-by: Vlastimil Babka
> ---
>
> Resend because Andrew's email was bounced back at so
(1):
mm/mincore: make mincore() more conservative
Vlastimil Babka (1):
mm/mincore: provide mapped status when cached status is not allowed
mm/mincore.c | 80
1 file changed, 68 insertions(+), 12 deletions(-)
--
2.20.1
na
Signed-off-by: Vlastimil Babka
Acked-by: Josh Snyder
Acked-by: Michal Hocko
Signed-off-by: Jiri Kosina
Signed-off-by: Vlastimil Babka
---
mm/mincore.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/mm/mincore.c b/mm/mincore.c
index 218099b5ed31..c3
are also other
existing ways anyway.
Cc: Jiri Kosina
Cc: Dominique Martinet
Cc: Andy Lutomirski
Cc: Dave Chinner
Cc: Kevin Easton
Cc: Matthew Wilcox
Cc: Cyril Hrubis
Cc: Tejun Heo
Cc: Kirill A. Shutemov
Cc: Daniel Gruss
Signed-off-by: Vlastimil Babka
---
mm/mincore.c | 67 +++
On 3/6/19 8:00 PM, Alexandre Ghiti wrote:
> This condition allows to define alloc_contig_range, so simplify
> it into a more accurate naming.
>
> Suggested-by: Vlastimil Babka
> Signed-off-by: Alexandre Ghiti
Acked-by: Vlastimil Babka
(you could have sent this with
On 2/25/19 9:30 PM, Roman Gushchin wrote:
> Vmalloc() is getting more and more used these days (kernel stacks,
> bpf and percpu allocator are new top users), and the total %
> of memory consumed by vmalloc() can be pretty significant
> and changes dynamically.
>
> /proc/meminfo is the best place
On 2/25/19 9:30 PM, Roman Gushchin wrote:
> alloc_vmap_area() is allocating memory for the vmap_area, and
> performing the actual lookup of the vm area and vmap_area
> initialization.
>
> This prevents us from using a pre-allocated memory for the map_area
> structure, which can be used in some
On 3/1/19 2:21 PM, Alexandre Ghiti wrote:
> I collected mistakes here: domain name expired and no mailing list added :)
> Really sorry about that, I missed the whole discussion (if any).
> Could someone forward it to me (if any) ? Thanks !
Bounced you David and Mike's discussion (4 messages
On 3/1/19 1:16 PM, Andrey Ryabinin wrote:
> A slightly better version of __split_huge_page();
>
> Signed-off-by: Andrey Ryabinin
Ack.
> Cc: Vlastimil Babka
> Cc: Mel Gorman
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Rik van Riel
> Cc: William Kucharski
>
On 2/27/19 1:04 AM, Dan Williams wrote:
> On Tue, Feb 26, 2019 at 4:00 PM Andrew Morton
> wrote:
>>
>> On Fri, 15 Feb 2019 18:51:51 + Mark Brown wrote:
>>
>>> On Fri, Feb 15, 2019 at 10:43:25AM -0800, Andrew Morton wrote:
On Fri, 15 Feb 2019 10:20:10 -0800 (PST) "kernelci.org bot"
On 2/28/2019 10:44 PM, John Hubbard wrote:
> Instead of removing that function, let's change it, and add another
> (since you have two cases: either a page* or a pgdat* is available),
> and move it to where it can compile, like this:
>
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
>
] [k] free_unref_page
>3.65% cat [kernel.kallsyms] [k] __list_add_valid
>3.19% cat [kernel.kallsyms] [k] __purge_vmap_area_lazy
>3.10% cat [kernel.kallsyms] [k] find_vmap_area
>3.05% cat [kernel.kallsyms] [k] rcu_cblist_dequeue
>
> Signed-off-by: Roman Gushchin
> Cc: Johannes Weiner
> Cc: Matthew Wilcox
Acked-by: Vlastimil Babka
On 2/27/19 3:47 PM, Aneesh Kumar K.V wrote:
> This patch adds PF_MEMALLOC_NOCMA which make sure any allocation in that
> context
> is marked non-movable and hence cannot be satisfied by CMA region.
>
> This is useful with get_user_pages_longterm where we want to take a page pin
> by
> migrating
On 2/28/19 9:33 AM, Andrey Ryabinin wrote:
> workingset_eviction() doesn't use and never did use the @mapping argument.
> Remove it.
>
> Signed-off-by: Andrey Ryabinin
> Acked-by: Johannes Weiner
> Acked-by: Rik van Riel
Acked-by: Vlastimil Babka
> Cc: Michal Hocko
On 2/27/19 10:32 PM, Oscar Salvador wrote:
> On Tue, Feb 26, 2019 at 02:04:28PM -0800, Andrew Morton wrote:
>> How is this going to affect existing userspace which is aware of the
>> current behaviour?
>
> Well, current behavior is not really predictable.
> Our customer was "surprised" that the
On 2/26/19 9:40 AM, Lars Persson wrote:
>> What about CC stable and a Fixes tag, would it be applicable here?
>>
>
> Yes this is candidate for stable so let's add:
> Cc:
>
> I do not find a good candidate for a Fixes tag.
How bout a version range where the bug needs to be fixed then?
On 2/19/19 1:32 PM, Lars Persson wrote:
> Our MIPS 1004Kc SoCs were seeing random userspace crashes with SIGILL
> and SIGSEGV that could not be traced back to a userspace code
> bug. They had all the magic signs of an I/D cache coherency issue.
>
> Now recently we noticed that the
On 2/22/19 6:58 PM, Andrey Ryabinin wrote:
> In a presence of more than 1 memory cgroup in the system our reclaim
> logic is just suck. When we hit memory limit (global or a limit on
> cgroup with subgroups) we reclaim some memory from all cgroups.
> This is sucks because, the cgroup that
On 2/22/19 6:43 PM, Andrey Ryabinin wrote:
> The argument 'unsigned long *lru_pages' passed around with no purpose,
> remove it.
>
> Signed-off-by: Andrey Ryabinin
With what Johannes has said,
Acked-by: Vlastimil Babka
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc:
On 2/22/19 6:43 PM, Andrey Ryabinin wrote:
> too_many_isolated() in mm/compaction.c looks only at node state,
> so it makes more sense to change argument to pgdat instead of zone.
>
> Signed-off-by: Andrey Ryabinin
Acked-by: Vlastimil Babka
> Cc: Johannes Weiner
> Cc:
nes[page_zonenum(page)]->zone_pgdat->lru_lock
> while we can simply do
> _DATA(page_to_nid(page))->lru_lock
Heh, well spotted.
>
> Remove zone_lru_lock() function, since it's only complicate things.
> Use 'page_pgdat(page)->lru_lock' pattern instead.
>
> Sign
On 2/22/19 6:43 PM, Andrey Ryabinin wrote:
> workingset_eviction() doesn't use and never did use the @mapping argument.
> Remove it.
>
> Signed-off-by: Andrey Ryabinin
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Rik van Riel
> Cc: Mel Gor
_DEFINE5(mremap) for
the non-MMAP_FIXED case. So unless there's further refactoring, the
check is still needed.
>>
>> [1]
>> https://lore.kernel.org/lkml/20190219155320.tkfkwvqk53tfd...@d104.suse.de/
>>
>> Signed-off-by: Oscar Salvador
Acked-by: Vlastimil Babka
On 2/19/19 4:53 PM, Oscar Salvador wrote:
> On Mon, Feb 18, 2019 at 02:15:35PM +0300, Kirill A. Shutemov wrote:
>> On Mon, Feb 18, 2019 at 10:57:18AM +0100, Vlastimil Babka wrote:
>>> IMHO it makes sense to do all such resource limit checks upfront. It
>>> should a
On 2/14/19 9:38 PM, Andrew Morton wrote:
> On Thu, 14 Feb 2019 12:45:51 + Peng Fan wrote:
>
>> In case cma_init_reserved_mem failed, need to free the memblock allocated
>> by memblock_reserve or memblock_alloc_range.
>>
>> ...
>>
>> --- a/mm/cma.c
>> +++ b/mm/cma.c
>> @@ -353,12 +353,14 @@
reeing pages.
>
> Acked-by: Michal Hocko
> Cc: Dave Hansen
> Signed-off-by: Dan Williams
Here's another fixlet to fold into
mm-move-buddy-list-manipulations-into-helpers.patch
This time not critical.
8<
>From 05aaff61f62f86e646c4a2581fe2ff63ff66a199 Mon Sep 17 00:00
On 2/18/19 6:31 PM, Zi Yan wrote:
> The purpose of proposing exchange_pages() is to avoid allocating any new
> page,
> so that we would not trigger any potential page reclaim or memory
> compaction.
> Allocating a temporary page defeats the purpose.
Compaction can only happen for order > 0
On 2/18/19 9:33 AM, Oscar Salvador wrote:
>
> Hi all,
>
> I would like to bring up a topic that comes from an issue a customer of ours
> is facing with the mremap syscall + hitting the max_map_count threshold:
>
> When passing the MREMAP_FIXED flag, mremap() calls mremap_to() which does the
>
to make it more accurate: this value being false
> does not mean that the system cannot use gigantic pages, it just means that
> runtime allocation of gigantic pages is not supported, one can still
> allocate boottime gigantic pages if the architecture supports it.
>
> Sig
On 2/13/19 8:30 PM, Dave Hansen wrote:
>> -#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) ||
>> defined(CONFIG_CMA)
>> +#ifdef CONFIG_COMPACTION_CORE
>> static __init int gigantic_pages_init(void)
>> {
>> /* With compaction or CMA we can allocate gigantic pages at
On 1/20/19 3:42 AM, Changbin Du wrote:
> Move the PAGE_OWNER option from submenu "Compile-time checks and compiler
> options" to dedicated submenu "Memory Debugging".
>
> Signed-off-by: Changbin Du
Acked-by: Vlastimil Babka
On 1/22/19 11:51 PM, Nicolas Boichat wrote:
> Hi Andrew,
>
> On Fri, Jan 11, 2019 at 6:21 PM Joerg Roedel wrote:
>>
>> On Wed, Jan 02, 2019 at 01:51:45PM +0800, Nicolas Boichat wrote:
>> > Does anyone have any further comment on this series? If not, which
>> > maintainer is going to pick this
;mm: reclaim small amounts of memory when an external
> fragmentation event occurs")
> Reported-and-tested-by: Yury Norov
> Tested-by: Will Deacon
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Thanks, sorry for the noise before.
> ---
> mm/page_alloc.
On 2/13/19 2:19 PM, Mel Gorman wrote:
> Yury Norov reported that an arm64 KVM instance could not boot since after
> v5.0-rc1 and could addressed by reverting the patches
>
> 1c30844d2dfe272d58c ("mm: reclaim small amounts of memory when an external
> 73444bc4d8f92e46a20 ("mm, page_alloc: do not
On 1/17/19 7:39 PM, Alexandre Ghiti wrote:
> From: Alexandre Ghiti
>
> On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but
> that support gigantic pages, boottime reserved gigantic pages can not be
> freed at all. This patchs simply enables the possibility to hand back
>
t presented, there was a 31% reduction in migration
> scanning and a 8% reduction on system CPU usage. A 2-socket machine showed
> similar benefits.
>
> [vba...@suse.cz: Migrate block that was found-fast, some optimisations]
> Signed-off-by: Mel Gorman
With the followup fix,
Acked-by: Vlastimil Babka
.
>
> Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup")
> Cc: sta...@vger.kernel.org # 4.14.y 4.19.y
> Signed-off-by: Sandeep Patil
Acked-by: Vlastimil Babka
Thanks.
> ---
>
> v1->v2
> --
> - Move pss_locked accounting into smaps_account() inline with pss
On 2/1/19 3:51 PM, Mel Gorman wrote:
> On Thu, Jan 31, 2019 at 03:52:10PM +0100, Vlastimil Babka wrote:
>>> -/* Reorder the free list to reduce repeated future searches */
>>> +/*
>>> + * Used when scanning for a suitable migration target which scans freelists
>>
On 2/1/19 10:11 AM, Michal Hocko wrote:
> On Fri 01-02-19 10:04:23, Vlastimil Babka wrote:
>> The side channel exists anyway as long as process can e.g. check if
>> its rss shrinked, and I doubt we are going to remove that possibility.
>
> Well, but rss update will not tell
On 1/31/19 11:09 AM, Michal Hocko wrote:
> On Wed 30-01-19 13:44:20, Vlastimil Babka wrote:
>> After "mm/mincore: make mincore() more conservative" we sometimes restrict
>> the
>> information about page cache residency, which we have to do without breaking
>>
Cc: Kevin Easton
Cc: Matthew Wilcox
Cc: Cyril Hrubis
Cc: Tejun Heo
Cc: Kirill A. Shutemov
Cc: Daniel Gruss
Signed-off-by: Jiri Kosina
Signed-off-by: Vlastimil Babka
Acked-by: Josh Snyder
Acked-by: Michal Hocko
---
mm/mincore.c | 17 -
1 file changed, 16 insertions(+), 1 d
or the free scanner indicating that there is less redundant work.
>
> Compaction migrate scanned 2081536219573286
> Compaction free scanned 1635261211510663
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Nit below:
...
> @@ -819,6 +870,7 @@ static inli
good thing.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Compaction migrate scanned2160727120116887
> Compaction free scanned 9533640616668703
>
> It's also the first time in the series where the number of pages scanned
> by the migration scanner is greater than the free scanner due to the
> increased search efficiency.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
y.
>
> [dan.carpen...@oracle.com: Fix static checker warning]
> [vba...@suse.cz: Correct number of pages scanned for lower orders]
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Small fix below:
> -/* Reorder the free list to reduce repeated future searches */
On 1/31/19 2:55 PM, Vlastimil Babka wrote:
> On 1/18/19 6:51 PM, Mel Gorman wrote:
> ...
>
>> +for (order = cc->order - 1;
>> + order >= PAGE_ALLOC_COSTLY_ORDER && pfn == cc->migrate_pfn &&
>> nr_scanned < limit;
>> +
On 1/18/19 6:51 PM, Mel Gorman wrote:
...
> + for (order = cc->order - 1;
> + order >= PAGE_ALLOC_COSTLY_ORDER && pfn == cc->migrate_pfn &&
> nr_scanned < limit;
> + order--) {
> + struct free_area *area = >zone->free_area[order];
> + struct
On 1/31/19 1:04 PM, Daniel Gruss wrote:
> On 1/30/19 1:44 PM, Vlastimil Babka wrote:
>> Close that sidechannel by always initiating readahead on the cache if we
>> encounter a cache miss for preadv2(RWF_NOWAIT); with that in place, probing
>> the pagecache residency itself w
to recognize reclaimed pages anyway.
Cc: Jiri Kosina
Cc: Dominique Martinet
Cc: Andy Lutomirski
Cc: Dave Chinner
Cc: Kevin Easton
Cc: Matthew Wilcox
Cc: Cyril Hrubis
Cc: Tejun Heo
Cc: Kirill A. Shutemov
Cc: Daniel Gruss
Signed-off-by: Vlastimil Babka
---
mm/mincore.c | 49
for the I/O
Vlastimil Babka (1):
mm/mincore: provide mapped status when cached status is not allowed
mm/filemap.c | 2 --
mm/mincore.c | 54
2 files changed, 42 insertions(+), 14 deletions(-)
--
2.20.1
Lutomirski
Cc: Dave Chinner
Cc: Kevin Easton
Cc: Matthew Wilcox
Cc: Cyril Hrubis
Cc: Tejun Heo
Cc: Kirill A. Shutemov
Cc: Daniel Gruss
Signed-off-by: Jiri Kosina
Signed-off-by: Vlastimil Babka
---
mm/filemap.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/filemap.c b/mm/filem
Cc: Kirill A. Shutemov
Cc: Daniel Gruss
Signed-off-by: Jiri Kosina
Signed-off-by: Vlastimil Babka
---
mm/mincore.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mm/mincore.c b/mm/mincore.c
index 218099b5ed31..747a4907a3ac 100644
--- a/mm/mincore.c
+++ b/mm
On 1/29/19 1:15 AM, Andrew Morton wrote:
> On Sun, 20 Jan 2019 17:10:49 -0800 Sandeep Patil wrote:
>
>> The 'pss_locked' field of smaps_rollup was being calculated incorrectly
>> as it accumulated the current pss everytime a locked VMA was found.
>>
>> Fix that by making sure we record the
On 1/28/19 9:57 AM, Sergey Senozhatsky wrote:
> Hello,
>
> next-20190125
>
> kcompactd0 is spinning on something, burning CPUs in the meantime:
Hi, could you check/add this to the earlier thread? Thanks.
https://lore.kernel.org/lkml/2019012625.GB27513@amd/T/#u
>
> %CPU TIME+
On 1/18/19 5:49 AM, Linus Torvalds wrote:
> On Fri, Jan 18, 2019 at 9:45 AM Vlastimil Babka wrote:
>>
>> Or maybe we could resort to the 5.0-rc1 page table check (that is now being
>> reverted) but only in cases when we are not allowed the page cache residen
On 1/4/19 1:50 PM, Mel Gorman wrote:
> Remote compaction is expensive and possibly counter-productive. Locality
> is expected to often have better performance characteristics than remote
> high-order pages. For small allocations, it's expected that locality is
> generally required or fallbacks are
On 1/4/19 1:50 PM, Mel Gorman wrote:
> Compaction is inherently race-prone as a suitable page freed during
> compaction can be allocated by any parallel task. This patch uses a
> capture_control structure to isolate a page immediately when it is freed
> by a direct compactor in the slow path of
On 1/4/19 1:50 PM, Mel Gorman wrote:
> Pageblock hints are cleared when compaction restarts or kswapd makes enough
> progress that it can sleep but it's over-eager in that the bit is cleared
> for migration sources with no LRU pages and migration targets with no free
> pages. As pageblock skip
On 1/4/19 1:50 PM, Mel Gorman wrote:
> Once fast searching finishes, there is a possibility that the linear
> scanner is scanning full blocks found by the fast scanner earlier. This
> patch uses an adaptive stride to sample pageblocks for free pages. The
> more consecutive full pageblocks
. By co-incidence, the 2-socket results showed a 54% reduction in
> the free scanner but will not be universally true.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 1/17/19 8:39 PM, Mel Gorman wrote:
> On Thu, Jan 17, 2019 at 06:58:30PM +0100, Vlastimil Babka wrote:
>> On 1/4/19 1:50 PM, Mel Gorman wrote:
>> > The fast isolation of pages can move the scanner faster than is necessary
>> > depending on the contents of the free
On 1/17/19 6:11 PM, Mel Gorman wrote:
> On Thu, Jan 17, 2019 at 05:38:36PM +0100, Vlastimil Babka wrote:
>> > rate but also by the fact that the scanners do not meet for longer when
>> > pageblocks are actually used. Overall this is justified and completing
>> > a pa
On 1/16/2019 8:52 AM, Josh Snyder wrote:
> On Tue, Jan 15, 2019 at 10:34 PM Dominique Martinet
> wrote:
>>
>> There is a difference with your previous patch though, that used to list no
>> page in core when it didn't know; this patch lists pages as in core when it
>> refuses to tell. I don't
On 1/4/19 1:50 PM, Mel Gorman wrote:
> The fast isolation of pages can move the scanner faster than is necessary
> depending on the contents of the free list. This patch will only allow
> the fast isolation to initialise the scanner and advance it slowly. The
> primary means of moving the scanner
actor that (clumsily) limited THP fault
latencies. Seems like it's (no longer?) the case, or the lock contention
detection alone works as well.
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
> ---
> mm/compaction.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletio
htly clearer. It could potentially be
> merged with earlier patches but it just makes the review slightly
> harder.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
ut it's useless
> work. Any benefit depends heavily on whether the scanners restarted
> recently so overall the reduction in scan rates is a mere 2.8% which
> is borderline noise.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
My easlier suggestion to check more thorough
can rates are reduced by 32% and system CPU usage is reduced by
> 2.6%. The 2-socket results are not materially different.
Hmm, interesting that adjusting migrate scanner affected free scanner. Oh well.
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
Nit below.
> ---
> mm/c
by the fact that the scanners do not meet for longer when
> pageblocks are actually used. Overall this is justified and completing
> a pageblock scan is very important for later patches.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
migration/free scanner did not happen in this case. When it does happen,
> the scan rates multiple by factors measured in the hundreds and would be
> misleading to present.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 1/4/19 1:49 PM, Mel Gorman wrote:
> Similar to the migration scanner, this patch uses the free lists to quickly
> locate a migration target. The search is different in that lower orders
> will be searched for a suitable high PFN if necessary but the search
> is still bound. This is justified on
89.72 ( 0.00%) 93.59 ( 4.32%)
>
> Compaction migrate scanned5416830625516488
> Compaction free scanned 80053095487603321
>
> Migration scan rates are reduced by 52%.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 1/16/19 5:15 PM, Mel Gorman wrote:
> On Wed, Jan 16, 2019 at 04:45:59PM +0100, Vlastimil Babka wrote:
>> On 1/4/19 1:49 PM, Mel Gorman wrote:
>> > Due to either a fast search of the free list or a linear scan, it is
>> > possible for multiple compaction instances
On 1/17/19 3:33 AM, syzbot wrote:
> Hello> syzbot found the following crash on:
>
> HEAD commit:b808822a75a3 Add linux-next specific files for 20190111
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16a471d8c0
> kernel config:
On 1/4/19 1:49 PM, Mel Gorman wrote:
> Due to either a fast search of the free list or a linear scan, it is
> possible for multiple compaction instances to pick the same pageblock
> for migration. This is lucky for one scanner and increased scanning for
> all the others. It also allows a race
On 1/16/19 3:33 PM, Mel Gorman wrote:
>>> + break;
>>> + }
>>> +
>>> + /*
>>> +* If low PFNs are being found and discarded then
>>> +* limit the scan as fast searching is finding
>>> +
On 1/4/19 1:49 PM, Mel Gorman wrote:
> The migration scanner is a linear scan of a zone with a potentiall large
> search space. Furthermore, many pageblocks are unusable such as those
> filled with reserved pages or partially filled with pages that cannot
> migrate. These still get scanned in the
d 2-socket machines for THP-intensive
> allocation during fragmentation the success rate was increased by less
> than 1% which is marginal. However, detailed tracing indicated that
> failure of migration due to a premature ENOMEM triggered by watermark
> checks were eliminated.
>
> Si
On 1/4/19 1:49 PM, Mel Gorman wrote:
> release_pages() is a simpler version of free_unref_page_list() but it
> tracks the highest PFN for caching the restart point of the compaction
> free scanner. This patch optionally tracks the highest PFN in the core
> helper and converts compaction to use it.
On 1/4/19 1:49 PM, Mel Gorman wrote:
> Reserved pages are set at boot time, tend to be clustered and almost never
> become unreserved. When isolating pages for either migration sources or
> target, skip the entire pageblock is one PageReserved page is encountered
> on the grounds that it is highly
On 1/4/19 1:49 PM, Mel Gorman wrote:
> It's non-obvious that high-order free pages are split into order-0 pages
> from the function name. Fix it.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
his was enough to briefly clarify the
> flow.
>
> No functional change.
>
> Signed-off-by: Mel Gorman
Acked-by: Vlastimil Babka
On 1/5/19 2:28 AM, Andrew Morton wrote:
> On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka wrote:
>
>>> Yes, it doesn't and it's not trivial to do. The tool reports uses of
>>> unint _values_. Values don't necessary reside in memory. It can be a
>>> register
On 11/26/18 8:27 PM, Hugh Dickins wrote:
> Waiting on a page migration entry has used wait_on_page_locked() all
> along since 2006: but you cannot safely wait_on_page_locked() without
> holding a reference to the page, and that extra reference is enough to
> make migrate_page_move_mapping() fail
On 1/7/19 12:08 PM, Dominique Martinet wrote:
>
> With the current mincore change, it will think everything was "in core"
> and not flush anything unless my option to just fadvise dontneed
> everything is passed though ; so even if we can make it work it is a
> change of behaviour that is breaking
On 1/7/19 5:32 AM, Dominique Martinet wrote:
> Linus Torvalds wrote on Sat, Jan 05, 2019:
>> But I think my patch to just rip out all that page lookup, and just
>> base it on the page table state has the fundamental advantage that it
>> gets rid of code. Maybe I should jst commit it, and see if
801 - 900 of 6104 matches
Mail list logo
