Commit 530d4c0c authored by Mike Rapoport's avatar Mike Rapoport Committed by Linus Torvalds

docs/boot-time-mm: remove bootmem documentation

Link: default avatarMike Rapoport <>
Cc: Catalin Marinas <>
Cc: Chris Zankel <>
Cc: "David S. Miller" <>
Cc: Geert Uytterhoeven <>
Cc: Greentime Hu <>
Cc: Greg Kroah-Hartman <>
Cc: Guan Xuetao <>
Cc: Ingo Molnar <>
Cc: "James E.J. Bottomley" <>
Cc: Jonas Bonn <>
Cc: Jonathan Corbet <>
Cc: Ley Foon Tan <>
Cc: Mark Salter <>
Cc: Martin Schwidefsky <>
Cc: Matt Turner <>
Cc: Michael Ellerman <>
Cc: Michal Hocko <>
Cc: Michal Simek <>
Cc: Palmer Dabbelt <>
Cc: Paul Burton <>
Cc: Richard Kuo <>
Cc: Richard Weinberger <>
Cc: Rich Felker <>
Cc: Russell King <>
Cc: Serge Semin <>
Cc: Thomas Gleixner <>
Cc: Tony Luck <>
Cc: Vineet Gupta <>
Cc: Yoshinori Sato <>
Signed-off-by: default avatarAndrew Morton <>
Signed-off-by: default avatarLinus Torvalds <>
parent 57c8a661
......@@ -5,54 +5,23 @@ Boot time memory management
Early system initialization cannot use "normal" memory management
simply because it is not set up yet. But there is still need to
allocate memory for various data structures, for instance for the
physical page allocator. To address this, a specialized allocator
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
introduced. Several years later PowerPC developers added a "Logical
Memory Blocks" allocator, which was later adopted by other
architectures and renamed to :ref:`memblock <memblock>`. There is also
a compatibility layer called `nobootmem` that translates bootmem
allocation interfaces to memblock calls.
physical page allocator.
The selection of the early allocator is done using
configuration options. These options are enabled or disabled
statically by the architectures' Kconfig files.
* Architectures that rely only on bootmem select
* The users of memblock with the nobootmem compatibility layer set
* And for those that use both memblock and bootmem the configuration
Whichever allocator is used, it is the responsibility of the
architecture specific initialization to set it up in
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
A specialized allocator called ``memblock`` performs the
boot time memory management. The architecture specific initialization
must set it up in :c:func:`setup_arch` and tear it down in
:c:func:`mem_init` functions.
Once the early memory management is available it offers a variety of
functions and macros for memory allocations. The allocation request
may be directed to the first (and probably the only) node or to a
particular node in a NUMA system. There are API variants that panic
when an allocation fails and those that don't. And more recent and
advanced memblock even allows controlling its own behaviour.
.. _bootmem:
when an allocation fails and those that don't.
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
Memory Manager" `book`_)
Memblock also offers a variety of APIs that control its own behaviour.
.. _book:
.. kernel-doc:: mm/bootmem.c
:doc: bootmem overview
.. _memblock:
Memblock Overview
.. kernel-doc:: mm/memblock.c
:doc: memblock overview
......@@ -61,26 +30,6 @@ Memblock
Functions and structures
Common API
The functions that are described in this section are available
regardless of what early memory manager is enabled.
.. kernel-doc:: mm/nobootmem.c
Bootmem specific API
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
.. kernel-doc:: include/linux/bootmem.h
.. kernel-doc:: mm/bootmem.c
Memblock specific API
Here is the description of memblock data structures, functions and
macros. Some of them are actually internal, but since they are
documented it would be silly to omit them. Besides, reading the
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment