From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: + docs-vm-update-memory-models-documentation.patch added to -mm tree Date: Mon, 13 Apr 2020 17:27:03 -0700 Message-ID: <20200414002703.uhqoQg8-j%akpm@linux-foundation.org> References: <20200412004155.1a8f4e081b4e03ef5903abb5@linux-foundation.org> Reply-To: linux-kernel@vger.kernel.org Return-path: Received: from mail.kernel.org ([198.145.29.99]:33476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727914AbgDNA1F (ORCPT ); Mon, 13 Apr 2020 20:27:05 -0400 In-Reply-To: <20200412004155.1a8f4e081b4e03ef5903abb5@linux-foundation.org> Sender: mm-commits-owner@vger.kernel.org List-Id: mm-commits@vger.kernel.org To: bcain@codeaurora.org, bhe@redhat.com, catalin.marinas@arm.com, corbet@lwn.net, dalias@libc.org, davem@davemloft.net, deller@gmx.de, geert@linux-m68k.org, gerg@linux-m68k.org, green.hu@gmail.com, guoren@kernel.org, gxt@pku.edu.cn, heiko.carstens@de.ibm.com, Hoan@os.amperecomputing.com, James.Bottomley@HansenPartnership.com, jcmvbkbc@gmail.com, ley.foon.tan@intel.com, linux@armlinux.org.uk, mattst88@gmail.com, mhocko@kernel.org, mm-commits@vger.kernel.org, monstr@monstr.eu, mpe@ellerman.id.au, msalter@redhat.com, nickhu@andestech.com, paul.walmsley@sifive.com, richard@nod.at, rppt@linux.ibm.com, shorne@gmail.com, tony.luck@intel.com, tsbogend@alpha.franken.de, vgupta@synopsys.com, ysato@users.sourceforge.jp The patch titled Subject: docs/vm: update memory-models documentation has been added to the -mm tree. Its filename is docs-vm-update-memory-models-documentation.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/docs-vm-update-memory-models-documentation.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/docs-vm-update-memory-models-documentation.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: Mike Rapoport Subject: docs/vm: update memory-models documentation To reflect the updates to free_area_init() family of functions. Link: http://lkml.kernel.org/r/20200412194859.12663-22-rppt@kernel.org Signed-off-by: Mike Rapoport Cc: Baoquan He Cc: Brian Cain Cc: Catalin Marinas Cc: "David S. Miller" Cc: Geert Uytterhoeven Cc: Greentime Hu Cc: Greg Ungerer Cc: Guan Xuetao Cc: Guo Ren Cc: Heiko Carstens Cc: Helge Deller Cc: Hoan Tran Cc: "James E.J. Bottomley" Cc: Jonathan Corbet Cc: Ley Foon Tan Cc: Mark Salter Cc: Matt Turner Cc: Max Filippov Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Simek Cc: Nick Hu Cc: Paul Walmsley Cc: Richard Weinberger Cc: Rich Felker Cc: Russell King Cc: Stafford Horne Cc: Thomas Bogendoerfer Cc: Tony Luck Cc: Vineet Gupta Cc: Yoshinori Sato Signed-off-by: Andrew Morton --- Documentation/vm/memory-model.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/Documentation/vm/memory-model.rst~docs-vm-update-memory-models-documentation +++ a/Documentation/vm/memory-model.rst @@ -46,11 +46,10 @@ maps the entire physical memory. For mos have entries in the `mem_map` array. The `struct page` objects corresponding to the holes are never fully initialized. -To allocate the `mem_map` array, architecture specific setup code -should call :c:func:`free_area_init_node` function or its convenience -wrapper :c:func:`free_area_init`. Yet, the mappings array is not -usable until the call to :c:func:`memblock_free_all` that hands all -the memory to the page allocator. +To allocate the `mem_map` array, architecture specific setup code should +call :c:func:`free_area_init` function. Yet, the mappings array is not +usable until the call to :c:func:`memblock_free_all` that hands all the +memory to the page allocator. If an architecture enables `CONFIG_ARCH_HAS_HOLES_MEMORYMODEL` option, it may free parts of the `mem_map` array that do not cover the _ Patches currently in -mm which might be from rppt@linux.ibm.com are mm-memblock-replace-dereferences-of-memblock_regionnid-with-api-calls.patch mm-make-early_pfn_to_nid-and-related-defintions-close-to-each-other.patch mm-remove-config_have_memblock_node_map-option.patch mm-free_area_init-use-maximal-zone-pfns-rather-than-zone-sizes.patch mm-use-free_area_init-instead-of-free_area_init_nodes.patch alpha-simplify-detection-of-memory-zone-boundaries.patch arm-simplify-detection-of-memory-zone-boundaries.patch arm64-simplify-detection-of-memory-zone-boundaries-for-uma-configs.patch csky-simplify-detection-of-memory-zone-boundaries.patch m68k-mm-simplify-detection-of-memory-zone-boundaries.patch parisc-simplify-detection-of-memory-zone-boundaries.patch sparc32-simplify-detection-of-memory-zone-boundaries.patch unicore32-simplify-detection-of-memory-zone-boundaries.patch xtensa-simplify-detection-of-memory-zone-boundaries.patch mm-remove-early_pfn_in_nid-and-config_nodes_span_other_nodes.patch mm-free_area_init-allow-defining-max_zone_pfn-in-descending-order.patch mm-rename-free_area_init_node-to-free_area_init_memoryless_node.patch mm-clean-up-free_area_init_node-and-its-helpers.patch mm-simplify-find_min_pfn_with_active_regions.patch docs-vm-update-memory-models-documentation.patch