The patch titled
Subject: mm: allow deferred page init for vmemmap only
has been added to the -mm tree. Its filename is
mm-allow-deferred-page-init-for-vmemmap-only.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-allow-deferred-page-init-for-vmemmap-only.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-allow-deferred-page-init-for-vmemmap-only.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
Subject: mm: allow deferred page init for vmemmap only
It is unsafe to do virtual to physical translations before mm_init() is
called if struct page is needed in order to determine the memory section
number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() we
initialize struct pages for all the allocated memory when deferred struct
pages are used.
My recent fix exposed this problem, because it greatly reduced number of
pages that are initialized before mm_init(), but the problem existed even
before my fix, as Fengguang Wu found.
Since FLATMEM is already disallowed for deferred struct pages, it makes
sense to allow deferred struct pages only on systems with
SPARSEMEM_VMEMMAP.
The problems are discussed in these threads:
http://lkml.kernel.org/r/20180418135300.inazvpxjxowogyge@xxxxxxxxxxxxxxxxxxxxxx
http://lkml.kernel.org/r/20180419013128.iurzouiqxvcnpbvz@xxxxxxxxxxxxxxxxxxxxxx
http://lkml.kernel.org/r/20180426202619.2768-1-pasha.tatashin@xxxxxxxxxx
Link: http://lkml.kernel.org/r/20180509191713.23794-1-pasha.tatashin@xxxxxxxxxx
Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set")
Signed-off-by: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
Reviewed-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: <steven.sistare@xxxxxxxxxx>
Cc: Daniel Jordan <daniel.m.jordan@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx>
Cc: Dennis Zhou <dennisszhou@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/Kconfig~mm-allow-deferred-page-init-for-vmemmap-only mm/Kconfig
--- a/mm/Kconfig~mm-allow-deferred-page-init-for-vmemmap-only
+++ a/mm/Kconfig
@@ -635,7 +635,7 @@ config DEFERRED_STRUCT_PAGE_INIT
bool "Defer initialisation of struct pages to kthreads"
default n
depends on NO_BOOTMEM
- depends on !FLATMEM
+ depends on SPARSEMEM_VMEMMAP
help
Ordinarily all struct pages are initialised during early boot in a
single thread. On very large machines this can take a considerable
_
Patches currently in -mm which might be from pasha.tatashin@xxxxxxxxxx are
mm-sections-are-not-offlined-during-memory-hotremove.patch
mm-allow-deferred-page-init-for-vmemmap-only.patch
sparc64-ng4-memset-32-bits-overflow.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
