summaryrefslogtreecommitdiff
path: root/erts/emulator/internal_doc/SuperCarrier.md
diff options
context:
space:
mode:
Diffstat (limited to 'erts/emulator/internal_doc/SuperCarrier.md')
-rw-r--r--erts/emulator/internal_doc/SuperCarrier.md14
1 files changed, 7 insertions, 7 deletions
diff --git a/erts/emulator/internal_doc/SuperCarrier.md b/erts/emulator/internal_doc/SuperCarrier.md
index f52c6613d5..55ac5a67af 100644
--- a/erts/emulator/internal_doc/SuperCarrier.md
+++ b/erts/emulator/internal_doc/SuperCarrier.md
@@ -12,7 +12,7 @@ Problem
-------
The initial motivation for this feature was customers asking for a way
-to pre-allocate physcial memory at VM start for it to use.
+to pre-allocate physical memory at VM start for it to use.
Other problems were different experienced limitations of the OS
implementation of mmap:
@@ -29,7 +29,7 @@ fragmentation increased.
Solution
--------
-Allocate one large continious area of address space at VM start and
+Allocate one large continuous area of address space at VM start and
then use that area to satisfy our dynamic memory need during
runtime. In other words: implement our own mmap.
@@ -70,7 +70,7 @@ name suggest that it can be viewed as our own mmap implementation.
A super carrier needs to satisfy two slightly different kinds of
allocation requests; multi block carriers (MBC) and single block
-carriers (SBC). They are both rather large blocks of continious
+carriers (SBC). They are both rather large blocks of continuous
memory, but MBCs and SBCs have different demands on alignment and
size.
@@ -79,13 +79,13 @@ alignment.
MBCs are more restricted. They can only have a number of fixed
sizes that are powers of 2. The start address need to have a very
-large aligment (currently 256 kb, called "super alignment"). This is a
+large alignment (currently 256 kb, called "super alignment"). This is a
design choice that allows very low overhead per allocated block in the
MBC.
To reduce fragmentation within the super carrier, it is good to keep SBCs
and MBCs apart. MBCs with their uniform alignment and sizes can be
-packed very efficiently together. SBCs without demand for aligment can
+packed very efficiently together. SBCs without demand for alignment can
also be allocated quite efficiently together. But mixing them can lead
to a lot of memory wasted when we need to create large holes of
padding to the next alignment limit.
@@ -102,9 +102,9 @@ The MBC area is called *sa* as in super aligned and the SBC area is
called *sua* as in super un-aligned.
Note that the "super" in super alignment and the "super" in super
-carrier has nothing to do with each other. We could have choosen
+carrier has nothing to do with each other. We could have chosen
another naming to avoid confusion, such as "meta" carrier or "giant"
-aligment.
+alignment.
+-------+ <---- sua.top
| sua |