Update Linux_Memory_Management_Essentials.md

Signed-off-by: Igor Stoppa <[email protected]>

Contributions/Linux_Memory_Management_Essentials.md

@@ -84,17 +84,19 @@ The following section presents a set of statements that can be objectively verif
    1. employment of physical pages - observing a physical memory page (e.g. a 4kB chunk aligned on a 4kB boundary) and how it is employed: what sort of content it might host, over time.
       1. certain physical pages are put to use for a specific purpose, which is (almost) immutable, for the entire duration of the execution of the kernel:
          1. kernel code from the boot image (except for pages containing kernel init code, which are released after kernel init is completed)
-         2. kernel statically allocated data from the monolithic portion (except for pages containing kernel init data, which are released after kernel init is completed)
+         2. kernel statically allocated data from the boot image (except for pages containing kernel init data, which are released after kernel init is completed)
          3. some kernel dynamically allocated data, used by the kernel itself, and never released, due to the nature of its use (e.g. object caches, persistent buffers, etc.)
-         4. memory used for loadable kernel modules (code, data) is tied to the permanence of the module in memory - this is typically stable through the entire duration of the execution. Some exceptions are modules loaded/unloaded as a consequence of certain peripherals (dis)appearing, e.g. USB ones.
+         4. memory used for loadable kernel modules (code, data) is tied to the permanence of the module in memory - this is very often stable through the entire duration of the execution. Some exceptions are modules loaded/unloaded as a consequence of certain peripherals (dis)appearing, e.g. USB ones.
       2. other physical pages (most, actually, in a typical system) are available for runtime allocation/release cycles of multiple users:
          1. transient kernel linear memory allocations (kmalloc / get_free_pages)
          2. transient kernel virtually linear memory allocations (vmalloc for kernel address space)
          3. user-space memory allocations (they are always virtually linear), which are by default transient and exposed to repurposing proactively done by the kernel (see below)
-   2. transitioning of a logical page - given certain context and content, where it might be located in memory over time - and if it might be even discarded.
+   2. location of the content a "logical" page: as seen by a process perspective, the content is always atthe same memory location, but in reality it can be moved around, over different physical pages. So, given a certain context and content, where it might be located in memory over time - and if it might be even discarded.
       1. the kernel doesn't spontaneously repurpose the utilisation of its own physical pages; therefore it is possible to assume that the logical content of kernel allocations will reamin tied to the associated physical pages, as long as it is not intentionally altered (or subject to interference)
-         1. metadata memory used by the kernel for housekeeping purposes related to processes is included in this category; examples: task/cred structures, vmas, maple leaves, process page tables.
-      2. memory used by the kernel for the actual userspace processes: the content of this logical page determines its life cycle and expectancy: certain content such as code or constants can be "re-constructed" by relaoding it from file (code pages are likely to necessitate undergoing re-linking), so the actual logical content might disappear, over time. Other pages, on the other hand, are meant to hold non-re-constructible content, such as stack, heap, and variable data. These pages can, at most, be swapped out, and loaded back later on, but they cannot be simply dropped.
+         1. metadata memory used by the kernel for housekeeping purposes related to processes is included in this category; examples: task/cred structures, vmas structures (not the vma pages), maple leaves, process page tables.
+      2. memory used by the kernel for the actual userspace processes: the content of this logical page determines its life cycle and expectancy:
+         1. Certain content such as code or constants can be "re-constructed", by relaoding it from file (code pages are likely to necessitate undergoing re-linking), so the actual logical content might disappear, over time.
+         2. Other pages, on the other hand, are meant to hold non-re-constructible content, such as stack, heap, and variable data. These pages can, at most, be swapped out, and loaded back later on, but they cannot be simply dropped.
       3. page cache: it is a collection of memory pages containing data read from files, over time; e.g. code or initialised data from a file that was accessed recently; in some cases the page might never have been used, but it was loaded as part of the readahaead optimisation. The life expectancy of these logical pages is heavily affected by how many processes might keep accesing them and the level of memory starvation of the system caused by other processes, with some additional complexity layered on top of this, by the use of containers.
    3. The kernel utilises various optimisations that are meant to take advantage of hardware features, such as multi-stage caching, and also to cope with different memory architectures (like Non Unifor Memory Architecture - NUMA). The main goals are:
       1. avoid having to propagate too frequently write operations through the layers of HW cache, which is caused by pages being evicted from the cache, due to memory pressure