linux-kernel - [PATCH 3/3] arm64: mm: Specify smaller page reporting order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Jun 2021 13:11:52 +0800
From:   Gavin Shan <gshan@...hat.com>
To:     linux-mm@...ck.org
Cc:     linux-kernel@...r.kernel.org, alexander.duyck@...il.com,
        akpm@...ux-foundation.org, david@...hat.com,
        anshuman.khandual@....com, catalin.marinas@....com,
        will@...nel.org, shan.gavin@...il.com
Subject: [PATCH 3/3] arm64: mm: Specify smaller page reporting order

The page reporting order is stick to @pageblock_order and its size
is 512MB when 64KB base page size is chosen. It also means the
page reporting won't be started if current freeing page can't come
up with a 512MB free area. It's hard when the system memory becomes
fragmented.

This specifies the page reporting order to 5 when the 64KB base page
size is chosen, corresponding to huge page size with 4KB base page
size, so that page reporting has more chance to work.

Cc: Anshuman Khandual <anshuman.khandual@....com>
Cc: Will Deacon <will@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>
Cc: linux-arm-kernel@...ts.infradead.org
Signed-off-by: Gavin Shan <gshan@...hat.com>
---
 arch/arm64/include/asm/page.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 012cffc574e8..b8386e7d7d47 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -18,6 +18,19 @@
 struct page;
 struct vm_area_struct;
 
+/*
+ * The page reporting won't be started if the freeing page can't come up
+ * with a huge page, which is 512MB with 64KB base page size. It's hard
+ * to have 512MB free area when the memory becomes fragmented, stop page
+ * reporting from working properly. So we choose smaller page reporting
+ * order, which is same to the huge page size (2MB) with 4KB base page
+ * size. However, more overheads will be introduced because page reporting
+ * will be running more frequently.
+ */
+#if defined(CONFIG_PAGE_REPORTING) && defined(CONFIG_ARM64_64K_PAGES)
+#define PAGE_REPORTING_ORDER 5
+#endif
+
 extern void copy_page(void *to, const void *from);
 extern void clear_page(void *to);
 
-- 
2.23.0