On Mon, Nov 05, 2018 at 01:12:40PM -0800, Matthew Wilcox wrote: > On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote: > > @@ -21,10 +21,10 @@ Virtual Memory Primer > > The physical memory in a computer system is a limited resource and > > even for systems that support memory hotplug there is a hard limit on > > the amount of memory that can be installed. The physical memory is not > > -necessary contiguous, it might be accessible as a set of distinct > > +necessary contiguous; it might be accessible as a set of distinct > > necessarily > > > address ranges. Besides, different CPU architectures, and even > > -different implementations of the same architecture have different view > > -how these address ranges defined. > > +different implementations of the same architecture have different views > > +of how these address ranges defined. > > "are defined"? > > > Each physical memory page can be mapped as one or more virtual > > pages. These mappings are described by page tables that allow > > -translation from virtual address used by programs to real address in > > -the physical memory. The page tables organized hierarchically. > > +translation from a virtual address used by programs to the real > > +address in the physical memory. The page tables are organized > > +hierarchically. > > I don't like the term "real address". Can we say "physical address in > memory" here, or "address of physical memory" or something? I didn't really like it as well, but I couldn't think of any better adjective to emphasize that address in the physical memory is "the real thing".
Maybe the best would be to drop "real" and make it "translation from a virtual address used by programs to the address in the physical memory" > > -page filled with zeroes. When the program performs a write, regular > > +page filled with zeroes. When the program performs a write, a regular > > physical page will be allocated to hold the written data. The page > > will be marked dirty and if the kernel will decide to repurpose it, > > the dirty page will be swapped out. > > "if the kernel will decide to repurpose it" is awkward. How about > > if the kernel decides to repurpose it"? > > > OOM killer > > ========== > > > > -It may happen, that on a loaded machine memory will be exhausted. When > > +It may happen that on a loaded machine memory will be exhausted. When > > the kernel detects that the system runs out of memory (OOM) it invokes > > `OOM killer`. > > Its mission is simple: all it has to do is to select a > > task to sacrifice for the sake of the overall system health. The > > It is possible for the kernel to be unable to reclaim enough memory to > continue to operate. In order to save the rest of the system, it invokes > the `OOM killer` to sacrifice one task. How about: It is possible that on a loaded machine memory will be exhausted and the kernel will be unable to reclaim enough memory to continue to operate. In order to save the rest of the system, it invokes the `OOM killer`. The `OOM killer` selects a task to sacrifice for the sake of the overall system health. The selected task is killed in a hope that after it exits enough memory will be freed to continue normal operation. -- Sincerely yours, Mike.
