All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-doc <linux-doc@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: [PATCH 10/11] docs/mm: memblock: add overview documentation
Date: Mon, 18 Jun 2018 19:59:58 +0300	[thread overview]
Message-ID: <1529341199-17682-11-git-send-email-rppt@linux.vnet.ibm.com> (raw)
In-Reply-To: <1529341199-17682-1-git-send-email-rppt@linux.vnet.ibm.com>

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
 mm/memblock.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/mm/memblock.c b/mm/memblock.c
index c4838a9..8bfeb82 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -26,6 +26,61 @@
 
 #include "internal.h"
 
+/**
+ * DOC: memblock overview
+ *
+ * Memblock is a method of managing memory regions during the early
+ * boot period when the usual kernel memory allocators are not up and
+ * running.
+ *
+ * Memblock views the system memory as collections of contiguous
+ * regions. There are several types of these collections:
+ *
+ * * ``memory`` - describes the physical memory available to the
+ *   kernel; this may differ from the actual physical memory installed
+ *   in the system, for instance when the memory is restricted with
+ *   ``mem=`` command line parameter
+ * * ``reserved`` - describes the regions that were allocated
+ * * ``physmap`` - describes the actual physical memory regardless of
+ *   the possible restrictions; the ``physmap`` type is only available
+ *   on some architectures.
+ *
+ * Each region is represented by :c:type:`struct memblock_region` that
+ * defines the region extents, its attributes and NUMA node id on NUMA
+ * systems. Every memory type is described by the :c:type:`struct
+ * memblock_type` which contains an array of memory regions along with
+ * the allocator metadata. The memory types are nicely wrapped with
+ * :c:type:`struct memblock`. This structure is statically initialzed
+ * at build time. The region arrays for the "memory" and "reserved"
+ * types are initially sized to %INIT_MEMBLOCK_REGIONS and for the
+ * "physmap" type to %INIT_PHYSMEM_REGIONS.
+ * The :c:func:`memblock_allow_resize` enables automatic resizing of
+ * the region arrays during addition of new regions. This feature
+ * should be used with care so that memory allocated for the region
+ * array will not overlap with areas that should be reserved, for
+ * example initrd.
+ *
+ * The early architecture setup should tell memblock what is the
+ * physical memory layout using :c:func:`memblock_add` or
+ * :c:func:`memblock_add_node` functions. The first function does not
+ * assign the region to a NUMA node and it is approptiate for UMA
+ * systems. Yet, it is possible to use it on NUMA systems as well and
+ * assign the region to a NUMA node later in the setup process using
+ * :c:func:`memblock_set_node`. The :c:func:`memblock_add_node`
+ * performs such an assignment directly.
+ *
+ * Once memblock is setup the memory can be allocated using either
+ * memblock or bootmem APIs.
+ *
+ * As the system boot progresses, the architecture specific
+ * :c:func:`mem_init` function frees all the memory to the buddy page
+ * allocator.
+ *
+ * If an architecure enables %CONFIG_ARCH_DISCARD_MEMBLOCK, the
+ * memblock data structures will be discarded after the system
+ * intialization compltes
+ */
+
 static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
 static struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
 #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
-- 
2.7.4


WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-doc <linux-doc@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: [PATCH 10/11] docs/mm: memblock: add overview documentation
Date: Mon, 18 Jun 2018 19:59:58 +0300	[thread overview]
Message-ID: <1529341199-17682-11-git-send-email-rppt@linux.vnet.ibm.com> (raw)
In-Reply-To: <1529341199-17682-1-git-send-email-rppt@linux.vnet.ibm.com>

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
 mm/memblock.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/mm/memblock.c b/mm/memblock.c
index c4838a9..8bfeb82 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -26,6 +26,61 @@
 
 #include "internal.h"
 
+/**
+ * DOC: memblock overview
+ *
+ * Memblock is a method of managing memory regions during the early
+ * boot period when the usual kernel memory allocators are not up and
+ * running.
+ *
+ * Memblock views the system memory as collections of contiguous
+ * regions. There are several types of these collections:
+ *
+ * * ``memory`` - describes the physical memory available to the
+ *   kernel; this may differ from the actual physical memory installed
+ *   in the system, for instance when the memory is restricted with
+ *   ``mem=`` command line parameter
+ * * ``reserved`` - describes the regions that were allocated
+ * * ``physmap`` - describes the actual physical memory regardless of
+ *   the possible restrictions; the ``physmap`` type is only available
+ *   on some architectures.
+ *
+ * Each region is represented by :c:type:`struct memblock_region` that
+ * defines the region extents, its attributes and NUMA node id on NUMA
+ * systems. Every memory type is described by the :c:type:`struct
+ * memblock_type` which contains an array of memory regions along with
+ * the allocator metadata. The memory types are nicely wrapped with
+ * :c:type:`struct memblock`. This structure is statically initialzed
+ * at build time. The region arrays for the "memory" and "reserved"
+ * types are initially sized to %INIT_MEMBLOCK_REGIONS and for the
+ * "physmap" type to %INIT_PHYSMEM_REGIONS.
+ * The :c:func:`memblock_allow_resize` enables automatic resizing of
+ * the region arrays during addition of new regions. This feature
+ * should be used with care so that memory allocated for the region
+ * array will not overlap with areas that should be reserved, for
+ * example initrd.
+ *
+ * The early architecture setup should tell memblock what is the
+ * physical memory layout using :c:func:`memblock_add` or
+ * :c:func:`memblock_add_node` functions. The first function does not
+ * assign the region to a NUMA node and it is approptiate for UMA
+ * systems. Yet, it is possible to use it on NUMA systems as well and
+ * assign the region to a NUMA node later in the setup process using
+ * :c:func:`memblock_set_node`. The :c:func:`memblock_add_node`
+ * performs such an assignment directly.
+ *
+ * Once memblock is setup the memory can be allocated using either
+ * memblock or bootmem APIs.
+ *
+ * As the system boot progresses, the architecture specific
+ * :c:func:`mem_init` function frees all the memory to the buddy page
+ * allocator.
+ *
+ * If an architecure enables %CONFIG_ARCH_DISCARD_MEMBLOCK, the
+ * memblock data structures will be discarded after the system
+ * intialization compltes
+ */
+
 static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
 static struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
 #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2018-06-18 17:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 16:59 [PATCH 00/11] docs/mm: add boot time memory management docs Mike Rapoport
2018-06-18 16:59 ` Mike Rapoport
2018-06-18 16:59 ` [PATCH 01/11] mm/bootmem: drop duplicated kernel-doc comments Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 16:59 ` [PATCH 02/11] docs/mm: nobootmem: fixup " Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 16:59 ` [PATCH 03/11] docs/mm: bootmem: fix kernel-doc warnings Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 16:59 ` [PATCH 04/11] docs/mm: bootmem: add kernel-doc description of 'struct bootmem_data' Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 17:25   ` Randy Dunlap
2018-06-18 17:25     ` Randy Dunlap
2018-06-18 16:59 ` [PATCH 05/11] docs/mm: bootmem: add overview documentation Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 17:15   ` Randy Dunlap
2018-06-18 17:15     ` Randy Dunlap
2018-06-18 16:59 ` [PATCH 06/11] mm/memblock: add a name for memblock flags enumeration Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 16:59 ` [PATCH 07/11] docs/mm: memblock: update kernel-doc comments Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 16:59 ` [PATCH 08/11] docs/mm: memblock: add kernel-doc comments for memblock_add[_node] Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 16:59 ` [PATCH 09/11] docs/mm: memblock: add kernel-doc description for memblock types Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 16:59 ` Mike Rapoport [this message]
2018-06-18 16:59   ` [PATCH 10/11] docs/mm: memblock: add overview documentation Mike Rapoport
2018-06-18 17:21   ` Randy Dunlap
2018-06-18 17:21     ` Randy Dunlap
2018-06-18 16:59 ` [PATCH 11/11] docs/mm: add description of boot time memory management Mike Rapoport
2018-06-18 16:59   ` Mike Rapoport
2018-06-18 17:32   ` Randy Dunlap
2018-06-18 17:32     ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1529341199-17682-11-git-send-email-rppt@linux.vnet.ibm.com \
    --to=rppt@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.