All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin He <Justin.He@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Anshuman Khandual <Anshuman.Khandual@arm.com>,
	Suzuki Poulose <Suzuki.Poulose@arm.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Dave P Martin <Dave.Martin@arm.com>,
	Steven Price <Steven.Price@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Gavin Shan <gshan@redhat.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Mark Brown <broonie@kernel.org>,
	Cristian Marussi <Cristian.Marussi@arm.com>
Subject: RE: [RFC PATCH 0/2] Avoid booting stall caused by idmap_kpti_install_ng_mappings
Date: Mon, 25 Jan 2021 06:36:51 +0000	[thread overview]
Message-ID: <AM6PR08MB4376549A9337A835B68F696DF7BD0@AM6PR08MB4376.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <AM6PR08MB43767517972A292A9AA15586F7A20@AM6PR08MB4376.eurprd08.prod.outlook.com>

Hi Marc

> -----Original Message-----
> From: Justin He
> Sent: Wednesday, January 20, 2021 11:56 PM
> To: Marc Zyngier <maz@kernel.org>
> Cc: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> <will@kernel.org>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Anshuman Khandual <Anshuman.Khandual@arm.com>;
> Suzuki Poulose <Suzuki.Poulose@arm.com>; Mark Rutland
> <Mark.Rutland@arm.com>; Gustavo A. R. Silva <gustavoars@kernel.org>;
> Richard Henderson <richard.henderson@linaro.org>; Dave P Martin
> <Dave.Martin@arm.com>; Steven Price <Steven.Price@arm.com>; Andrew Morton
> <akpm@linux-foundation.org>; Mike Rapoport <rppt@kernel.org>; Ard
> Biesheuvel <ardb@kernel.org>; Gavin Shan <gshan@redhat.com>; Kefeng Wang
> <wangkefeng.wang@huawei.com>; Mark Brown <broonie@kernel.org>; Cristian
> Marussi <Cristian.Marussi@arm.com>
> Subject: RE: [RFC PATCH 0/2] Avoid booting stall caused by
> idmap_kpti_install_ng_mappings
> 
> Hi Marc
> 
> > -----Original Message-----
> > From: Marc Zyngier <maz@kernel.org>
> > Sent: Wednesday, January 20, 2021 6:58 PM
> > To: Justin He <Justin.He@arm.com>
> > Cc: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> > <will@kernel.org>; linux-arm-kernel@lists.infradead.org; linux-
> > kernel@vger.kernel.org; Anshuman Khandual <Anshuman.Khandual@arm.com>;
> > Suzuki Poulose <Suzuki.Poulose@arm.com>; Mark Rutland
> > <Mark.Rutland@arm.com>; Gustavo A. R. Silva <gustavoars@kernel.org>;
> > Richard Henderson <richard.henderson@linaro.org>; Dave P Martin
> > <Dave.Martin@arm.com>; Steven Price <Steven.Price@arm.com>; Andrew Morton
> > <akpm@linux-foundation.org>; Mike Rapoport <rppt@kernel.org>; Ard
> > Biesheuvel <ardb@kernel.org>; Gavin Shan <gshan@redhat.com>; Kefeng Wang
> > <wangkefeng.wang@huawei.com>; Mark Brown <broonie@kernel.org>; Cristian
> > Marussi <Cristian.Marussi@arm.com>
> > Subject: Re: [RFC PATCH 0/2] Avoid booting stall caused by
> > idmap_kpti_install_ng_mappings
> >
> > Hi Justin,
> >
> > On 2021-01-20 04:51, Justin He wrote:
> > > Hi,
> > > Kindly ping 😊
> > >
> > >> -----Original Message-----
> > >> From: Jia He <justin.he@arm.com>
> > >> Sent: Wednesday, January 13, 2021 9:41 AM
> > >> To: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> > >> <will@kernel.org>; linux-arm-kernel@lists.infradead.org; linux-
> > >> kernel@vger.kernel.org
> > >> Cc: Anshuman Khandual <Anshuman.Khandual@arm.com>; Suzuki Poulose
> > >> <Suzuki.Poulose@arm.com>; Justin He <Justin.He@arm.com>; Mark Rutland
> > >> <Mark.Rutland@arm.com>; Gustavo A. R. Silva <gustavoars@kernel.org>;
> > >> Richard Henderson <richard.henderson@linaro.org>; Dave P Martin
> > >> <Dave.Martin@arm.com>; Steven Price <Steven.Price@arm.com>; Andrew
> > >> Morton
> > >> <akpm@linux-foundation.org>; Mike Rapoport <rppt@kernel.org>; Ard
> > >> Biesheuvel <ardb@kernel.org>; Gavin Shan <gshan@redhat.com>; Kefeng
> > >> Wang
> > >> <wangkefeng.wang@huawei.com>; Mark Brown <broonie@kernel.org>; Marc
> > >> Zyngier
> > >> <maz@kernel.org>; Cristian Marussi <Cristian.Marussi@arm.com>
> > >> Subject: [RFC PATCH 0/2] Avoid booting stall caused by
> > >>
> > >> There is a 10s stall in idmap_kpti_install_ng_mappings when kernel
> > >> boots
> > >> on a Ampere EMAG server.
> > >>
> > >> Commit f992b4dfd58b ("arm64: kpti: Add ->enable callback to remap
> > >> swapper using nG mappings") updates the nG bit runtime if kpti is
> > >> required.
> > >>
> > >> But things get worse if rodata=full in map_mem(). NO_BLOCK_MAPPINGS |
> > >> NO_CONT_MAPPINGS is required when creating pagetable mapping. Hence
> > >> all
> > >> ptes are fully mapped in this case. On a Ampere EMAG server with 256G
> > >> memory(pagesize=4k), it causes the 10s stall.
> > >>
> > >> After moving init_cpu_features() ahead of early_fixmap_init(), we can
> > >> use
> > >> cpu_have_const_cap earlier than before. Hence we can avoid this stall
> > >> by updating arm64_use_ng_mappings.
> > >>
> > >> After this patch series, it reduces the kernel boot time from 14.7s to
> > >> 4.1s:
> > >> Before:
> > >> [   14.757569] Freeing initrd memory: 60752K
> > >> After:
> > >> [    4.138819] Freeing initrd memory: 60752K
> > >>
> > >> Set it as RFC because I want to resolve any other points which I have
> > >> misconerned.
> >
> > But you don't really explain *why* having the CPU Feature discovery
> > early helps at all. Is that so that you can bypass the idmap mapping?
> 
> Adding nG bits can be avoided by having the discovery of boot cpu feature
> earlier since the nG bit had been set in PTE_MAYBE_NG/PMD_MAYBE_NG
> 
> Before this patch:
> 1. kernel will firstly create mapping in setup_arch->paging_init->map_mem
> -> __map_memblock
> 2. Then if kpti is required, kernel will add nG bits for each pte entry.
> 3. In extreme case, e.g. physical memory is 256G,rodata=full, and pagesize
> is 4K, the nG bits updating in step 2 takes about 10s.
> 
> > I'd expect something that explain the problem instead of paraphrasing
> > the patches.
> >
> > Another thing is whether you have tested this on some ThunderX HW
> 
> I will find a TX1 as you told to see any difference.
> 
> 
I fortunately found a cavium TX1. 
Seems that unmap_kernel_at_el0 is false:
...
[    0.000000] Machine model: Cavium ThunderX CN88XX board
...
[    0.000000] CPU features: kernel page table isolation forced OFF by ARM64_WORKAROUND_CAVIUM_27456
...

Hence no such stall *before* and *after* this patch set because kpti is not enabled.


--
Cheers,
Justin (Jia He)





WARNING: multiple messages have this Message-ID (diff)
From: Justin He <Justin.He@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Gavin Shan <gshan@redhat.com>,
	Suzuki Poulose <Suzuki.Poulose@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Anshuman Khandual <Anshuman.Khandual@arm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Cristian Marussi <Cristian.Marussi@arm.com>,
	Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Price <Steven.Price@arm.com>,
	Will Deacon <will@kernel.org>,
	Dave P Martin <Dave.Martin@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [RFC PATCH 0/2] Avoid booting stall caused by idmap_kpti_install_ng_mappings
Date: Mon, 25 Jan 2021 06:36:51 +0000	[thread overview]
Message-ID: <AM6PR08MB4376549A9337A835B68F696DF7BD0@AM6PR08MB4376.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <AM6PR08MB43767517972A292A9AA15586F7A20@AM6PR08MB4376.eurprd08.prod.outlook.com>

Hi Marc

> -----Original Message-----
> From: Justin He
> Sent: Wednesday, January 20, 2021 11:56 PM
> To: Marc Zyngier <maz@kernel.org>
> Cc: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> <will@kernel.org>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Anshuman Khandual <Anshuman.Khandual@arm.com>;
> Suzuki Poulose <Suzuki.Poulose@arm.com>; Mark Rutland
> <Mark.Rutland@arm.com>; Gustavo A. R. Silva <gustavoars@kernel.org>;
> Richard Henderson <richard.henderson@linaro.org>; Dave P Martin
> <Dave.Martin@arm.com>; Steven Price <Steven.Price@arm.com>; Andrew Morton
> <akpm@linux-foundation.org>; Mike Rapoport <rppt@kernel.org>; Ard
> Biesheuvel <ardb@kernel.org>; Gavin Shan <gshan@redhat.com>; Kefeng Wang
> <wangkefeng.wang@huawei.com>; Mark Brown <broonie@kernel.org>; Cristian
> Marussi <Cristian.Marussi@arm.com>
> Subject: RE: [RFC PATCH 0/2] Avoid booting stall caused by
> idmap_kpti_install_ng_mappings
> 
> Hi Marc
> 
> > -----Original Message-----
> > From: Marc Zyngier <maz@kernel.org>
> > Sent: Wednesday, January 20, 2021 6:58 PM
> > To: Justin He <Justin.He@arm.com>
> > Cc: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> > <will@kernel.org>; linux-arm-kernel@lists.infradead.org; linux-
> > kernel@vger.kernel.org; Anshuman Khandual <Anshuman.Khandual@arm.com>;
> > Suzuki Poulose <Suzuki.Poulose@arm.com>; Mark Rutland
> > <Mark.Rutland@arm.com>; Gustavo A. R. Silva <gustavoars@kernel.org>;
> > Richard Henderson <richard.henderson@linaro.org>; Dave P Martin
> > <Dave.Martin@arm.com>; Steven Price <Steven.Price@arm.com>; Andrew Morton
> > <akpm@linux-foundation.org>; Mike Rapoport <rppt@kernel.org>; Ard
> > Biesheuvel <ardb@kernel.org>; Gavin Shan <gshan@redhat.com>; Kefeng Wang
> > <wangkefeng.wang@huawei.com>; Mark Brown <broonie@kernel.org>; Cristian
> > Marussi <Cristian.Marussi@arm.com>
> > Subject: Re: [RFC PATCH 0/2] Avoid booting stall caused by
> > idmap_kpti_install_ng_mappings
> >
> > Hi Justin,
> >
> > On 2021-01-20 04:51, Justin He wrote:
> > > Hi,
> > > Kindly ping 😊
> > >
> > >> -----Original Message-----
> > >> From: Jia He <justin.he@arm.com>
> > >> Sent: Wednesday, January 13, 2021 9:41 AM
> > >> To: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> > >> <will@kernel.org>; linux-arm-kernel@lists.infradead.org; linux-
> > >> kernel@vger.kernel.org
> > >> Cc: Anshuman Khandual <Anshuman.Khandual@arm.com>; Suzuki Poulose
> > >> <Suzuki.Poulose@arm.com>; Justin He <Justin.He@arm.com>; Mark Rutland
> > >> <Mark.Rutland@arm.com>; Gustavo A. R. Silva <gustavoars@kernel.org>;
> > >> Richard Henderson <richard.henderson@linaro.org>; Dave P Martin
> > >> <Dave.Martin@arm.com>; Steven Price <Steven.Price@arm.com>; Andrew
> > >> Morton
> > >> <akpm@linux-foundation.org>; Mike Rapoport <rppt@kernel.org>; Ard
> > >> Biesheuvel <ardb@kernel.org>; Gavin Shan <gshan@redhat.com>; Kefeng
> > >> Wang
> > >> <wangkefeng.wang@huawei.com>; Mark Brown <broonie@kernel.org>; Marc
> > >> Zyngier
> > >> <maz@kernel.org>; Cristian Marussi <Cristian.Marussi@arm.com>
> > >> Subject: [RFC PATCH 0/2] Avoid booting stall caused by
> > >>
> > >> There is a 10s stall in idmap_kpti_install_ng_mappings when kernel
> > >> boots
> > >> on a Ampere EMAG server.
> > >>
> > >> Commit f992b4dfd58b ("arm64: kpti: Add ->enable callback to remap
> > >> swapper using nG mappings") updates the nG bit runtime if kpti is
> > >> required.
> > >>
> > >> But things get worse if rodata=full in map_mem(). NO_BLOCK_MAPPINGS |
> > >> NO_CONT_MAPPINGS is required when creating pagetable mapping. Hence
> > >> all
> > >> ptes are fully mapped in this case. On a Ampere EMAG server with 256G
> > >> memory(pagesize=4k), it causes the 10s stall.
> > >>
> > >> After moving init_cpu_features() ahead of early_fixmap_init(), we can
> > >> use
> > >> cpu_have_const_cap earlier than before. Hence we can avoid this stall
> > >> by updating arm64_use_ng_mappings.
> > >>
> > >> After this patch series, it reduces the kernel boot time from 14.7s to
> > >> 4.1s:
> > >> Before:
> > >> [   14.757569] Freeing initrd memory: 60752K
> > >> After:
> > >> [    4.138819] Freeing initrd memory: 60752K
> > >>
> > >> Set it as RFC because I want to resolve any other points which I have
> > >> misconerned.
> >
> > But you don't really explain *why* having the CPU Feature discovery
> > early helps at all. Is that so that you can bypass the idmap mapping?
> 
> Adding nG bits can be avoided by having the discovery of boot cpu feature
> earlier since the nG bit had been set in PTE_MAYBE_NG/PMD_MAYBE_NG
> 
> Before this patch:
> 1. kernel will firstly create mapping in setup_arch->paging_init->map_mem
> -> __map_memblock
> 2. Then if kpti is required, kernel will add nG bits for each pte entry.
> 3. In extreme case, e.g. physical memory is 256G,rodata=full, and pagesize
> is 4K, the nG bits updating in step 2 takes about 10s.
> 
> > I'd expect something that explain the problem instead of paraphrasing
> > the patches.
> >
> > Another thing is whether you have tested this on some ThunderX HW
> 
> I will find a TX1 as you told to see any difference.
> 
> 
I fortunately found a cavium TX1. 
Seems that unmap_kernel_at_el0 is false:
...
[    0.000000] Machine model: Cavium ThunderX CN88XX board
...
[    0.000000] CPU features: kernel page table isolation forced OFF by ARM64_WORKAROUND_CAVIUM_27456
...

Hence no such stall *before* and *after* this patch set because kpti is not enabled.


--
Cheers,
Justin (Jia He)




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

  reply	other threads:[~2021-01-25  6:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20  4:51 [RFC PATCH 0/2] Avoid booting stall caused by idmap_kpti_install_ng_mappings Justin He
2021-01-20 10:58 ` Marc Zyngier
2021-01-20 10:58   ` Marc Zyngier
2021-01-20 15:55   ` Justin He
2021-01-20 15:55     ` Justin He
2021-01-25  6:36     ` Justin He [this message]
2021-01-25  6:36       ` Justin 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=AM6PR08MB4376549A9337A835B68F696DF7BD0@AM6PR08MB4376.eurprd08.prod.outlook.com \
    --to=justin.he@arm.com \
    --cc=Anshuman.Khandual@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Cristian.Marussi@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Steven.Price@arm.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=gshan@redhat.com \
    --cc=gustavoars@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=richard.henderson@linaro.org \
    --cc=rppt@kernel.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.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 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.