linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Hubert Ralf <Ralf.Hubert@preh.de>
To: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"anshuman.khandual@arm.com" <anshuman.khandual@arm.com>
Subject: Re: [PATCH] aarch64/mm: speedup memory initialisation
Date: Thu, 12 Sep 2019 08:40:12 +0000	[thread overview]
Message-ID: <bf14a3cb2812c03d08c380fccc4ca336cb7b5352.camel@preh.de> (raw)
In-Reply-To: <645c9de8-d82a-8d51-ae4a-bcf903ccd1e5@arm.com>

Am Donnerstag, den 12.09.2019, 13:42 +0530 schrieb Anshuman Khandual:
> 
> On 09/10/2019 02:29 PM, 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.
> > 
> > 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
> 
> This is not required any more. Its gone with the following commit which
> also made generic memmap_init() an weak function currently overridden
> only on ia64.
> 
> dfb3ccd00a0 ("mm: make memmap_init a proper function")
> 
> > +	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 */
> 
> In generic mmap_init(), the current high cost comes from early_pfn_valid()
> check for each pfn in memmap_init_zone() given that early_pfn_valid() is
> pfn_valid() when CONFIG_SPARSEMEM which is known to be expensive on arm64.
> 
> Though we cannot do anything about pfns which are really present but the
> high cost for non present pfns should be eliminated. The following check
> in the above for_each_memblock() loop can achieve that.
> 
> if (reg->flags & MEMBLOCK_NOMAP)
> 	continue;
> 
> MEMBLOCK_NOMAP universally should not be initialized into a zone and holes
> if any should also be universally skipped across platforms. So these changes
> can be moved into generic memmap_init() which will benefit other platforms.
Not sure if I got this. This is a additional short path for memblocks with
the MEMBLOCK_NOMAP flag set, right? For memblocks without these flag the remaining
code still needs to be executed?

In my case I have 4 memblocks with 1.5GB RAM at 0x4000 0000, 0x4 8000 0000,
0x6 0000 0000 and 0x6 8000 0000. None of them has the MEMBLOCK_NOMAP flag set.
_______________________________________________
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-12  8:40 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
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 [this message]
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=bf14a3cb2812c03d08c380fccc4ca336cb7b5352.camel@preh.de \
    --to=ralf.hubert@preh.de \
    --cc=anshuman.khandual@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).