[PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k page kernels.

On 12 February 2016 at 17:43, Jeremy Linton [off-list ref] wrote:

On 02/12/2016 10:28 AM, Ard Biesheuvel wrote:

quoted

On 12 February 2016 at 17:21, Jeremy Linton [off-list ref] wrote:

quoted

On 02/12/2016 10:11 AM, Ard Biesheuvel wrote:

quoted

On 12 February 2016 at 17:06, Jeremy Linton [off-list ref]
wrote:

(trimming)

quoted

quoted

   #if defined(CONFIG_DEBUG_ALIGN_RODATA)
-#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
-#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
+#if defined(CONFIG_ARM64_64K_PAGES)
+#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
+#else
+#define ALIGN_DEBUG_RO_MIN(min)                . =
ALIGN(SECTION_SIZE);

Doesn't this align to 32 MB on 16k pages kernels?

Yes, I considered whether it was more appropriate to use CONT_SIZE for
16k
as well.

Opinions?

Looking at vmlinux.lds.S, I see that that would put _stext and
__init_begin at 32 MB aligned boundaries. making the size of the
kernel at least 64 MB. If I take your .rodata patch into account,
which adds a third instance of ALIGN_DEBUG_RO_MIN, the Image footprint
will rise to ~100 MB. Or am I missing something?

No, I think your correct. But, its an option, and it sort of depends on use
case. In a system with 100+GB of RAM it might be useful. Not so much on a
phone or small embedded system. I don't really see those people enabling
ALIGN_RODATA anyway. Worse, I expect the loss of RAM efficiently going from
4k-16k pages in a RAM constrained system to be a pretty big hit too.

I don't have any hard data one way or the other, and I don't have a strong
opinion. Although, I suspect at the moment the potential users of 16k pages
may tend toward the small side.

Well, the thing is, if you only use 2 MB of each 32 MB on average, you
gain nothing by going from contiguous pages to proper sections, since
the TLB footprint is the same. So my opinion would be to use CONT_SIZE
for 16k pages as well.