diff options
Diffstat (limited to 'erts/emulator/internal_doc/SuperCarrier.md')
-rw-r--r-- | erts/emulator/internal_doc/SuperCarrier.md | 14 |
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 | |