Hi Justin,
On 2021-01-20 04:51, Justin He wrote:
Hi,
Kindly ping 😊
-----Original Message-----
From: Jia He <[email protected]>
Sent: Wednesday, January 13, 2021 9:41 AM
To: Catalin Marinas <[email protected]>; Will Deacon
<[email protected]>; [email protected]; linux-
[email protected]
Cc: Anshuman Khandual <[email protected]>; Suzuki Poulose
<[email protected]>; Justin He <[email protected]>; Mark Rutland
<[email protected]>; Gustavo A. R. Silva <[email protected]>;
Richard Henderson <[email protected]>; Dave P Martin
<[email protected]>; Steven Price <[email protected]>; Andrew
Morton
<[email protected]>; Mike Rapoport <[email protected]>; Ard
Biesheuvel <[email protected]>; Gavin Shan <[email protected]>; Kefeng
Wang
<[email protected]>; Mark Brown <[email protected]>; Marc
Zyngier
<[email protected]>; Cristian Marussi <[email protected]>
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?
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
(the first version, not TX2), as this is the whole reason for this
code...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
