Thread (9 messages) flat view 9 messages, 4 authors, 2016-03-16
STALE3815d

Revision v3 of 12 in this series.

Revisions (12)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 [diff vs current]
  6. v2 [diff vs current]
  7. v3 [diff vs current]
  8. v3 [diff vs current]
  9. v3 current
  10. v3 [diff vs current]
  11. v3 [diff vs current]
  12. v3 [diff vs current]

[PATCH v3 2/2] arm64: Mark kernel page ranges contiguous

From: Jeremy Linton <hidden>
Date: 2016-02-22 15:39:28

On 02/22/2016 04:28 AM, Ard Biesheuvel wrote:
On 19 February 2016 at 18:46, Jeremy Linton [off-list ref] wrote:
quoted
With 64k pages, the next larger segment size is 512M. The linux
kernel also uses different protection flags to cover its code and data.
Because of these requirements, the vast majority of the kernel code and
data structures end up being mapped with 64k pages instead of the larger
pages common with a 4k page kernel.

Recent ARM processors support a contiguous bit in the
page tables which allows a TLB to cover a range larger than a
single PTE if that range is mapped into physically contiguous
RAM.

So, for the kernel its a good idea to set this flag. Some basic
micro benchmarks show it can significantly reduce the number of
L1 dTLB refills.

Signed-off-by: Jeremy Linton <redacted>
Tested on 4k/3 levels, and the page tables look correct to me

Tested-by: Ard Biesheuvel <redacted>
Thanks,
You didn't answer my question though, regarding implementing this at
the PMD level for 16k pages kernels, so that we can use 1 GB chunks
for mapping system RAM. Would that just be a matter of doing the exact
same thing at the PMD level? Or is it more complicated than that?
AFAIK, yes. It should be similar with the PMD ranges being unmarked on 
permission change or PTE allocation.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help