Skip to content

arm64: simplify and optimize kernel mapping

Jeremy Linton linux-arm-kernel 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. 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.

Read the v1 thread

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 __init section (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_CONT patch 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 MEM

After:

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_SIZE alignment when CONFIG_DEBUG_ALIGN_RODATA=y, but the net effect of patch #3 is the same (only the Kconfig change 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,