arm64: simplify and optimize kernel mapping
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] arm64: simplify and optimize kernel mapping
Quoted 53 lines · Mark Rutland
Hi,
I like this series, though I have a few minor comments below.
Quoted 6 lines · Ard Biesheuvel
This series makes a couple of minor changes that should result in the kernel being mapped in a more efficient manner.
First of all, it merges the .head.text with the .text section (patch #2) after moving everything except the kernel and EFI header into the
__initsection (patch #1)Face-to-face, you suggested it might be possible to move .init before .text, so we could place the EFI header in there too (and keep .text aligned while making it smaller). Is there some reason we missed that means we cannot do this?
Quoted 4 lines
Then, it standardizes the segment alignment to 64 KB for all page sizes. (patch #3). In the example below (4 KB granule, with Jeremy's
PTE_CONTpatch applied), we lose 80 KB in total to padding, but the resulting mappings do look somewhat better.I suspect some people might want a minimal alignment option for tinification purposes, but this sounds fine to me as a default. I also think we can wait until someone asks.
As a general think, currently we use "chunk" instead of "segment" in the mm code. We only used "chunk" so as to not overload "section". For consistency it would be nice to either keep with "chunk" or convert existing uses to "segment". I much prefer the latter!
Quoted 23 lines
Before:
0xffff000008082000-0xffff000008090000 56K ro x SHD AF UXN MEM 0xffff000008090000-0xffff000008200000 1472K ro x SHD AF CON UXN MEM 0xffff000008200000-0xffff000008600000 4M ro x SHD AF BLK UXN MEM 0xffff000008600000-0xffff000008660000 384K ro x SHD AF CON UXN MEM 0xffff000008660000-0xffff00000866c000 48K ro x SHD AF UXN MEM 0xffff00000866c000-0xffff000008670000 16K ro NX SHD AF UXN MEM 0xffff000008670000-0xffff000008900000 2624K ro NX SHD AF CON UXN MEM 0xffff000008900000-0xffff000008909000 36K ro NX SHD AF UXN MEM 0xffff000008c39000-0xffff000008c40000 28K RW NX SHD AF UXN MEM 0xffff000008c40000-0xffff000008d50000 1088K RW NX SHD AF CON UXN MEM 0xffff000008d50000-0xffff000008d57000 28K RW NX SHD AF UXN MEMAfter:
0xffff000008080000-0xffff000008200000 1536K ro x SHD AF CON UXN MEM 0xffff000008200000-0xffff000008600000 4M ro x SHD AF BLK UXN MEM 0xffff000008600000-0xffff000008670000 448K ro x SHD AF CON UXN MEM 0xffff000008670000-0xffff000008910000 2688K ro NX SHD AF CON UXN MEM 0xffff000008c50000-0xffff000008d60000 1088K RW NX SHD AF CON UXN MEM 0xffff000008d60000-0xffff000008d6b000 44K RW NX SHD AF UXN MEM
Quoted 5 lines
Quoted 3 lines
I am aware that this clashes with Jeremy's patch to allow
CONT_SIZEalignment whenCONFIG_DEBUG_ALIGN_RODATA=y, but the net effect of patch #3 is the same (only theKconfigchange is not included here)Jeremy, do you have any thoughts on this series?
I was waiting to see if anyone questioned padding the minimum kernel
alignment. But other than that, It looks good.
I've been meaning to test it at 64k pages to see how much rearranging
everything helps. I guess I will be rolling another CONT set to address Will's reluctance to have the extra TLB flushes (and probably rework the block break case as well) unless someone decides they want this now. I will make sure that these two patch sets merge cleanly when I do that.
Thanks,