public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm•com>
To: Hubert Ralf <Ralf.Hubert@preh•de>,
	"linux-arm-kernel@lists•infradead.org"
	<linux-arm-kernel@lists•infradead.org>
Subject: Re: [PATCH] aarch64/mm: speedup memory initialisation
Date: Tue, 10 Sep 2019 14:07:09 +0100	[thread overview]
Message-ID: <0b23bdf5-e9ed-6281-c9d4-304818ce74c4@arm.com> (raw)
In-Reply-To: <20190910085822.27072-1-ralf.hubert@preh.de>

On 10/09/2019 09:59, Hubert Ralf wrote:
> On ARM64 memmap_init_zone is used during bootmem_init, which iterates over
> all pages in the memory starting at the lowest address until the highest
> address is reached. On arm64 this ends up in searching a memmory region
> containing for each single page between lowest and highest available
> physicall address.
> 
> Having a sparse memory system there may be some big holes in the
> memory map. For each page in this holes a lookup is done, which is
> implemented as a binary search on the available memory blocks.

It sounds like that's one of the many related issues for which the real 
solution is "handle EFI no-map regions in a way which makes pfn_valid() 
not terrible" - if we are prepared to have workarounds for individual 
hot-spots, they should probably carry a big reminder to put things back 
once pfn_valid() is sorted out.

That said, even with the current implementation, the memblock search is 
short-circuited by the valid_section() check, so the impact should 
already be limited to just boundary regions where RAM is weirdly aligned 
and a hole starts or ends mid-section. Of course, regardless of any 
check overhead there might well still be an argument for not walking 
through large avoidable holes one PFN at a time, but the rationale as 
given doesn't seem to quite add up.

Robin.

> Adding a memmap_init for aarch64 to do the init only for the available
> memory areas reduces the time needed for initialising memory on startup.
> On a Renesas R-CAR M3 based system with a total hole of 20GB bootmem_init
> execution time is reduced from 378ms to 84ms.
> 
> Signed-off-by: Ralf Hubert <ralf.hubert@preh•de>
> ---
>   arch/arm64/include/asm/pgtable.h |  7 +++++++
>   arch/arm64/mm/init.c             | 24 ++++++++++++++++++++++++
>   2 files changed, 31 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e09760ece844..8c6eefc08b0b 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -298,6 +298,13 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
>   	return (lhs == rhs);
>   }
>   
> +#ifdef CONFIG_SPARSEMEM
> +/* arch mem_map init routine is needed due to holes in a memmap */
> +#   define __HAVE_ARCH_MEMMAP_INIT
> +	void memmap_init(unsigned long size, int nid, unsigned long zone,
> +			 unsigned long start_pfn);
> +#endif /* CONFIG_SPARSEMEM */
> +
>   /*
>    * Huge pte definitions.
>    */
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f3c795278def..206b28310872 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -250,6 +250,30 @@ int pfn_valid(unsigned long pfn)
>   }
>   EXPORT_SYMBOL(pfn_valid);
>   
> +#ifdef CONFIG_SPARSEMEM
> +void __meminit
> +memmap_init(unsigned long size, int nid, unsigned long zone,
> +	    unsigned long start_pfn)
> +{
> +	struct memblock_region *reg;
> +
> +	for_each_memblock(memory, reg) {
> +		unsigned long start = memblock_region_memory_base_pfn(reg);
> +		unsigned long end = memblock_region_memory_end_pfn(reg);
> +
> +		if (start < start_pfn)
> +			start = start_pfn;
> +		if (end > start_pfn + size)
> +			end = start_pfn + size;
> +
> +		if (start < end) {
> +			memmap_init_zone(end - start, nid, zone, start,
> +					 MEMMAP_EARLY, NULL);
> +		}
> +	}
> +}
> +#endif /* CONFIG_SPARSEMEM */
> +
>   static phys_addr_t memory_limit = PHYS_ADDR_MAX;
>   
>   /*
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-09-10 13:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10  8:59 [PATCH] aarch64/mm: speedup memory initialisation Hubert Ralf
2019-09-10 13:07 ` Robin Murphy [this message]
2019-09-11 16:22 ` James Morse
2019-09-12  5:36   ` Hubert Ralf
2019-09-12  8:12 ` Anshuman Khandual
2019-09-12  8:40   ` Hubert Ralf
2019-09-12  8:59     ` Anshuman Khandual

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=0b23bdf5-e9ed-6281-c9d4-304818ce74c4@arm.com \
    --to=robin.murphy@arm$(echo .)com \
    --cc=Ralf.Hubert@preh$(echo .)de \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox