All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jia He <hejianet@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Michal Hocko <mhocko@suse.com>,
	Wei Yang <richard.weiyang@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Laura Abbott <labbott@redhat.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	Philip Derrin <philip@cog.systems>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	James Morse <james.morse@arm.com>,
	Steve Capper <steve.capper@arm.com>,
	Pavel Tatashin <pasha.tatashin@oracle.com>,
	Gioh Kim <gi-oh.kim@profitbricks.com>,
	Vlastimil Babka <vbabka@suse.cz>, Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Kemi Wang <kemi.wang@intel.com>, Petr Tesarik <ptesarik@suse.com>,
	YASUAKI ISHIMATSU <yasu.isimatu@gmail.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Nikolay Borisov <nborisov@suse.com>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	Daniel Vacek <neelx@redhat.com>,
	Eugeniu Rosca <erosca@de.adit-jv.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RESEND PATCH v10 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64
Date: Fri, 6 Jul 2018 15:41:35 -0700	[thread overview]
Message-ID: <20180706154135.1bbb6f4999f664a2ffadbc53@linux-foundation.org> (raw)
In-Reply-To: <1530867675-9018-1-git-send-email-hejianet@gmail.com>

On Fri,  6 Jul 2018 17:01:09 +0800 Jia He <hejianet@gmail.com> wrote:

> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
> where possible") optimized the loop in memmap_init_zone(). But it causes
> possible panic bug. So Daniel Vacek reverted it later.
> 
> But as suggested by Daniel Vacek, it is fine to using memblock to skip
> gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.
> 
> More from what Daniel said:
> "On arm and arm64, memblock is used by default. But generic version of
> pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
> not always return the next valid one but skips more resulting in some
> valid frames to be skipped (as if they were invalid). And that's why
> kernel was eventually crashing on some !arm machines."
> 
> About the performance consideration:
> As said by James in b92df1de5,
> "I have tested this patch on a virtual model of a Samurai CPU with a
> sparse memory map.  The kernel boot time drops from 109 to 62 seconds."
> Thus it would be better if we remain memblock_next_valid_pfn on arm/arm64.
> 
> Besides we can remain memblock_next_valid_pfn, there is still some room
> for improvement. After this set, I can see the time overhead of memmap_init
> is reduced from 27956us to 13537us in my armv8a server(QDF2400 with 96G
> memory, pagesize 64k). I believe arm server will benefit more if memory is
> larger than TBs

It's a shame that we're at v10, still with very little evidence of
review activity.

Oh well, it's a nice speedup.  I'll toss it in and see what happens,
but I'm not very familiar with memblock so we should try to find
reviewers, please.


WARNING: multiple messages have this Message-ID (diff)
From: akpm@linux-foundation.org (Andrew Morton)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH v10 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64
Date: Fri, 6 Jul 2018 15:41:35 -0700	[thread overview]
Message-ID: <20180706154135.1bbb6f4999f664a2ffadbc53@linux-foundation.org> (raw)
In-Reply-To: <1530867675-9018-1-git-send-email-hejianet@gmail.com>

On Fri,  6 Jul 2018 17:01:09 +0800 Jia He <hejianet@gmail.com> wrote:

> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
> where possible") optimized the loop in memmap_init_zone(). But it causes
> possible panic bug. So Daniel Vacek reverted it later.
> 
> But as suggested by Daniel Vacek, it is fine to using memblock to skip
> gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.
> 
> More from what Daniel said:
> "On arm and arm64, memblock is used by default. But generic version of
> pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
> not always return the next valid one but skips more resulting in some
> valid frames to be skipped (as if they were invalid). And that's why
> kernel was eventually crashing on some !arm machines."
> 
> About the performance consideration:
> As said by James in b92df1de5,
> "I have tested this patch on a virtual model of a Samurai CPU with a
> sparse memory map.  The kernel boot time drops from 109 to 62 seconds."
> Thus it would be better if we remain memblock_next_valid_pfn on arm/arm64.
> 
> Besides we can remain memblock_next_valid_pfn, there is still some room
> for improvement. After this set, I can see the time overhead of memmap_init
> is reduced from 27956us to 13537us in my armv8a server(QDF2400 with 96G
> memory, pagesize 64k). I believe arm server will benefit more if memory is
> larger than TBs

It's a shame that we're at v10, still with very little evidence of
review activity.

Oh well, it's a nice speedup.  I'll toss it in and see what happens,
but I'm not very familiar with memblock so we should try to find
reviewers, please.

  parent reply	other threads:[~2018-07-06 22:41 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06  9:01 [RESEND PATCH v10 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64 Jia He
2018-07-06  9:01 ` Jia He
2018-07-06  9:01 ` [RESEND PATCH v10 1/6] arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID Jia He
2018-07-06  9:01   ` Jia He
2018-08-17 14:50   ` Catalin Marinas
2018-08-17 14:50     ` Catalin Marinas
2018-08-20  6:27     ` Jia He
2018-08-20  6:27       ` Jia He
2018-07-06  9:01 ` [RESEND PATCH v10 2/6] mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64 Jia He
2018-07-06  9:01   ` Jia He
2018-07-06 22:37   ` Andrew Morton
2018-07-06 22:37     ` Andrew Morton
2018-07-09  3:30     ` Jia He
2018-07-09  3:30       ` Jia He
2018-07-09  3:30       ` Jia He
2018-08-16 22:54   ` Pasha Tatashin
2018-08-16 22:54     ` Pasha Tatashin
2018-08-16 22:54     ` Pasha Tatashin
2018-07-06  9:01 ` [RESEND PATCH v10 3/6] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn() Jia He
2018-07-06  9:01   ` Jia He
2018-08-17  1:08   ` Pasha Tatashin
2018-08-17  1:08     ` Pasha Tatashin
2018-08-17  1:08     ` Pasha Tatashin
2018-08-17  1:22     ` Pasha Tatashin
2018-08-17  1:22       ` Pasha Tatashin
2018-08-17  1:22       ` Pasha Tatashin
2018-08-21  6:14     ` Jia He
2018-08-21  6:14       ` Jia He
2018-08-21  6:14       ` Jia He
2018-08-21 21:08       ` Andrew Morton
2018-08-21 21:08         ` Andrew Morton
2018-08-21 21:08         ` Andrew Morton
2018-08-22  1:38         ` Jia He
2018-08-22  1:38           ` Jia He
2018-08-22  1:38           ` Jia He
2018-07-06  9:01 ` [RESEND PATCH v10 4/6] mm/memblock: introduce memblock_search_pfn_regions() Jia He
2018-07-06  9:01   ` Jia He
2018-07-06  9:01 ` [RESEND PATCH v10 5/6] mm/memblock: introduce pfn_valid_region() Jia He
2018-07-06  9:01   ` Jia He
2018-07-06  9:01 ` [RESEND PATCH v10 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid() Jia He
2018-07-06  9:01   ` Jia He
2018-08-17  1:35   ` Pasha Tatashin
2018-08-17  1:35     ` Pasha Tatashin
2018-08-17  1:35     ` Pasha Tatashin
2018-08-17  1:38     ` Pavel Tatashin
2018-08-17  1:38       ` Pavel Tatashin
2018-08-17  1:38       ` Pavel Tatashin
2018-08-17  5:38     ` Jia He
2018-08-17  5:38       ` Jia He
2018-08-17  5:38       ` Jia He
2018-07-06 22:41 ` Andrew Morton [this message]
2018-07-06 22:41   ` [RESEND PATCH v10 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64 Andrew Morton
2018-08-15 22:34 ` Andrew Morton
2018-08-15 22:34   ` Andrew Morton
2018-08-16 19:02   ` Pasha Tatashin
2018-08-16 19:02     ` Pasha Tatashin
2018-08-16 19:02     ` Pasha Tatashin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180706154135.1bbb6f4999f664a2ffadbc53@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.m.jordan@oracle.com \
    --cc=erosca@de.adit-jv.com \
    --cc=gi-oh.kim@profitbricks.com \
    --cc=hannes@cmpxchg.org \
    --cc=hejianet@gmail.com \
    --cc=james.morse@arm.com \
    --cc=keescook@chromium.org \
    --cc=kemi.wang@intel.com \
    --cc=labbott@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=nborisov@suse.com \
    --cc=neelx@redhat.com \
    --cc=pasha.tatashin@oracle.com \
    --cc=philip@cog.systems \
    --cc=ptesarik@suse.com \
    --cc=richard.weiyang@gmail.com \
    --cc=steve.capper@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=vbabka@suse.cz \
    --cc=vladimir.murzin@arm.com \
    --cc=will.deacon@arm.com \
    --cc=yasu.isimatu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.