All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugeniu Rosca <erosca@de.adit-jv.com>
To: Jia He <hejianet@gmail.com>
Cc: Daniel Vacek <neelx@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mel Gorman <mgorman@suse.de>, Will Deacon <will.deacon@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Pavel Tatashin <pasha.tatashin@oracle.com>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Gioh Kim <gi-oh.kim@profitbricks.com>,
	Steven Sistare <steven.sistare@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	open list <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	James Morse <james.morse@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Steve Capper <steve.capper@arm.com>, <x86@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	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>,
	Jia He <jia.he@hxt-semitech.com>,
	Eugeniu Rosca <erosca@de.adit-jv.com>
Subject: Re: [PATCH 1/4] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()
Date: Thu, 22 Mar 2018 13:52:04 +0100	[thread overview]
Message-ID: <20180322125204.GA8892@vmlxhi-102.adit-jv.com> (raw)
In-Reply-To: <3f208ebe-572f-f2f6-003e-5a9cf49bb92f@gmail.com>

On Wed, Mar 21, 2018 at 08:28:18PM +0800, Jia He wrote:
> 
> 
> On 3/21/2018 6:14 PM, Daniel Vacek Wrote:
> >On Wed, Mar 21, 2018 at 9:09 AM, 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 there is
> >>still some room for improvement. E.g. if pfn and pfn+1 are in the same
> >>memblock region, we can simply pfn++ instead of doing the binary search
> >>in memblock_next_valid_pfn.
> >There is a revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible.patch
> >in -mm reverting b92df1de5d289c0b as it is fundamentally wrong by
> >design causing system panics on some machines with rare but still
> >valid mappings. Basically it skips valid pfns which are outside of
> >usable memory ranges (outside of memblock memory regions).
> Thanks for the infomation.
> quote from you patch description:
> >But given some specific memory mapping on x86_64 (or more generally
> theoretically anywhere but on arm with CONFIG_HAVE_ARCH_PFN_VALID) > the
> implementation also skips valid pfns which is plain wrong and causes >
> 'kernel BUG at mm/page_alloc.c:1389!'
> 
> Do you think memblock_next_valid_pfn can remain to be not reverted on arm64
> with CONFIG_HAVE_ARCH_PFN_VALID? Arm64 can benifit from this optimization.

I confirm that the boot time of Rcar-H3 arm64 platform greatly
benefits from v4.11-rc1 commit b92df1de5d28 ("mm: page_alloc: skip over
regions of invalid pfns where possible"). The startup improvement is
roughly ~140ms, which will be lost if the mentioned commit is reverted.

For more details on my measurements, please see linux-next commit
283f1645e236 ("mm: page_alloc: skip over regions of invalid pfns on
UMA").

Whichever way you decide to go forward (reimplement/fix b92df1de5d28
or create an <arch>_next_valid_pfn), I am willing to participate in
testing your proposals on RCAR SoCs. TIA.

Thanks,
Eugeniu.

WARNING: multiple messages have this Message-ID (diff)
From: Eugeniu Rosca <erosca@de.adit-jv.com>
To: Jia He <hejianet@gmail.com>
Cc: Daniel Vacek <neelx@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mel Gorman <mgorman@suse.de>, Will Deacon <will.deacon@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Pavel Tatashin <pasha.tatashin@oracle.com>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Gioh Kim <gi-oh.kim@profitbricks.com>,
	Steven Sistare <steven.sistare@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	open list <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, James Morse <james.morse@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Steve Capper <steve.capper@arm.com>,
	x86@kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	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>,
	Jia He <jia.he@hxt-semitech.com>,
	Eugeniu Rosca <erosca@de.adit-jv.com>
Subject: Re: [PATCH 1/4] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()
Date: Thu, 22 Mar 2018 13:52:04 +0100	[thread overview]
Message-ID: <20180322125204.GA8892@vmlxhi-102.adit-jv.com> (raw)
In-Reply-To: <3f208ebe-572f-f2f6-003e-5a9cf49bb92f@gmail.com>

On Wed, Mar 21, 2018 at 08:28:18PM +0800, Jia He wrote:
> 
> 
> On 3/21/2018 6:14 PM, Daniel Vacek Wrote:
> >On Wed, Mar 21, 2018 at 9:09 AM, 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 there is
> >>still some room for improvement. E.g. if pfn and pfn+1 are in the same
> >>memblock region, we can simply pfn++ instead of doing the binary search
> >>in memblock_next_valid_pfn.
> >There is a revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible.patch
> >in -mm reverting b92df1de5d289c0b as it is fundamentally wrong by
> >design causing system panics on some machines with rare but still
> >valid mappings. Basically it skips valid pfns which are outside of
> >usable memory ranges (outside of memblock memory regions).
> Thanks for the infomation.
> quote from you patch description:
> >But given some specific memory mapping on x86_64 (or more generally
> theoretically anywhere but on arm with CONFIG_HAVE_ARCH_PFN_VALID) > the
> implementation also skips valid pfns which is plain wrong and causes >
> 'kernel BUG at mm/page_alloc.c:1389!'
> 
> Do you think memblock_next_valid_pfn can remain to be not reverted on arm64
> with CONFIG_HAVE_ARCH_PFN_VALID? Arm64 can benifit from this optimization.

I confirm that the boot time of Rcar-H3 arm64 platform greatly
benefits from v4.11-rc1 commit b92df1de5d28 ("mm: page_alloc: skip over
regions of invalid pfns where possible"). The startup improvement is
roughly ~140ms, which will be lost if the mentioned commit is reverted.

For more details on my measurements, please see linux-next commit
283f1645e236 ("mm: page_alloc: skip over regions of invalid pfns on
UMA").

Whichever way you decide to go forward (reimplement/fix b92df1de5d28
or create an <arch>_next_valid_pfn), I am willing to participate in
testing your proposals on RCAR SoCs. TIA.

Thanks,
Eugeniu.

  parent reply	other threads:[~2018-03-22 12:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21  8:09 [PATCH RFC 0/4] optimize memblock_next_valid_pfn() and early_pfn_valid() Jia He
2018-03-21  8:09 ` [PATCH 1/4] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn() Jia He
2018-03-21 10:14   ` Daniel Vacek
2018-03-21 12:28     ` Jia He
2018-03-21 15:04       ` Daniel Vacek
2018-03-22 12:52       ` Eugeniu Rosca [this message]
2018-03-22 12:52         ` Eugeniu Rosca
2018-03-21  8:09 ` [PATCH 2/4] mm/memblock: introduce memblock_search_pfn_regions() Jia He
2018-03-21 10:14   ` Daniel Vacek
2018-03-21 12:04     ` Jia He
2018-03-21  8:09 ` [PATCH 3/4] arm64: introduce pfn_valid_region() Jia He
2018-03-21  8:09 ` [PATCH 4/4] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid() Jia He

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=20180322125204.GA8892@vmlxhi-102.adit-jv.com \
    --to=erosca@de.adit-jv.com \
    --cc=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=gi-oh.kim@profitbricks.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hejianet@gmail.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jia.he@hxt-semitech.com \
    --cc=kemi.wang@intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=nborisov@suse.com \
    --cc=neelx@redhat.com \
    --cc=pasha.tatashin@oracle.com \
    --cc=pombredanne@nexb.com \
    --cc=ptesarik@suse.com \
    --cc=steve.capper@arm.com \
    --cc=steven.sistare@oracle.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --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.