OSTEP chapter 17

pages/hls__ostep_1680491762166_0.md

@@ -509,22 +509,22 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
   ls-type:: annotation
   id:: 642faf44-5876-46b3-acb4-b786f390716f
   hl-color:: yellow
-- paranoid
+- paranoid 多疑的；偏执狂；妄想症患者
-  ls-type:: annotation
   hl-page:: 142
-  hl-color:: green
+  ls-type:: annotation
   id:: 642fb2f2-b9a4-48f4-b847-2b30d632db32
-- rage
+  hl-color:: green
-  ls-type:: annotation
+- rage 暴怒；狂怒;迅速蔓延；快速扩散:
   hl-page:: 143
-  hl-color:: green
-  id:: 642fb3d2-e51f-4b9b-8a79-dea9d8e6a7b0
-- inundated 
   ls-type:: annotation
-  hl-page:: 144
+  id:: 642fb3d2-e51f-4b9b-8a79-dea9d8e6a7b0
   hl-color:: green
+- inundate 泛滥；淹没；浸水；
+  hl-page:: 144
+  ls-type:: annotation
   id:: 642fb4c0-5c56-44e9-aac6-396212698309
-- errant
+  hl-color:: green
+- errant 周游的；不定的；错误的；偏离正路的
   ls-type:: annotation
   hl-page:: 145
   hl-color:: green
@@ -534,7 +534,7 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
   hl-page:: 146
   hl-color:: green
   id:: 642fb54e-23c4-4667-955d-ad09fbbf6268
-- pesky 
+- pesky 烦人的；让人讨厌的
   ls-type:: annotation
   hl-page:: 148
   hl-color:: green
@@ -545,11 +545,6 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
   id:: 642fbad1-cda0-4ef4-97f7-38c3519042f4
   hl-color:: yellow
 	- Goal: transparency, efficiency and protection
-- alas
-  ls-type:: annotation
-  hl-page:: 149
-  hl-color:: green
-  id:: 642fbb24-877c-4c90-9e13-4e613e2e23d3
 - tandem 
   ls-type:: annotation
   hl-page:: 150
@@ -581,6 +576,7 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
   hl-color:: yellow
   id:: 642fc48b-e5bf-4043-b042-218445c2b714
 	- Address space mapped to contiguous physical memory
+	  id:: 6430040b-bfaa-4148-a49a-1a22350e0c33
 	- Address space can be totally held in physical memory(no too big)
 	- Each address space is the same size.
 - Dynamic (Hardware-based) Relocation
@@ -640,7 +636,7 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
   hl-page:: 174
   hl-color:: green
   id:: 642fcff1-ae71-4756-9847-5ab85c41be06
-- oblivious 
+- oblivious 未察觉;不注意;忘记
   ls-type:: annotation
   hl-page:: 175
   hl-color:: green
@@ -650,7 +646,7 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
   hl-page:: 181
   hl-color:: yellow
   id:: 642fd5c3-30f9-4770-8ec5-09555d21c4ab
-	- Divide the address space into contiguous segments, and **the address space as a whole is no more contiguous in physical memory**.
+	- Divide the address space into contiguous segments, and **the address space as a whole is no more contiguous in physical memory**. ((6430040b-bfaa-4148-a49a-1a22350e0c33))
 	- A base and bounds pair per logical segment of the address space. Place each one of those segments in different parts of physical memory, and thus avoid filling physical memory with unused virtual address space. Conforming to this, MMU should add some registers.
 	- Selecting segment: which segment does a virtual address refer to?
 		- Explicit method: use the top few bits of the virtual address as segment selector, and the rest as in-segment offset.
@@ -674,5 +670,169 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
 	  id:: 642fe0dc-7d4b-41af-a136-69164ee77ab4
 	  hl-color:: yellow
 		- Attach several protection bits to Segment Register. For example, by setting code segment to read-only, you can safely share the segment across processes, thus saving the memory to hold a copy of code when a program creates many processes.
-	- Problem 1: variable-sized segments cause external fragments by chopping free memory into odd-sized pieces
+	- Problem 1: variable-sized segments cause ((64302439-30a1-4724-ab5f-0d90ab8530e2))
-	- Problem 2: not flexible enough. What if we want a large enough but sparsely-allocated heap(the heap segment could be very large but wastefully used)?
+	  id:: 6430040b-2a6e-4342-8db8-bc92893d0a3f
+	- Problem 2: not flexible enough. What if we want a large enough but sparsely-allocated heap(the heap segment could be very large but wastefully used)?
+- external fragmentation
+  hl-page:: 193
+  ls-type:: annotation
+  id:: 64302439-30a1-4724-ab5f-0d90ab8530e2
+  hl-color:: yellow
+	- the free space gets chopped into little pieces of different size(fragmented); subsequent requests may fail because there is no single contiguous space that can satisfy the request, even though the total amount of free space suffices.
+- Assumptions on free space management
+  hl-page:: 194
+  ls-type:: annotation
+  id:: 6430258a-4890-4fea-97c3-2d6bef20b251
+  hl-color:: yellow
+	- Assume a pair of interface `void* malloc(size_t size)` and `void free(void* ptr)`, and a generic data structure `free list`(not necessarily be a list)
+	- Ignore internal fragmentation
+	- No reallocation, no compaction
+	- Assume the allocator manages a contiguous and size-fixed region of bytes
+- coalesce 联合；合并
+  hl-page:: 195
+  ls-type:: annotation
+  id:: 64302a62-c183-4dbf-94de-1861deb192f4
+  hl-color:: green
+- intact 完整的；原封不动的；未受损伤的
+  ls-type:: annotation
+  hl-page:: 196
+  hl-color:: green
+  id:: 64302b20-f76e-4516-868f-0ecab376328f
+- corollary 必然的结果(或结论)
+  hl-page:: 196
+  ls-type:: annotation
+  id:: 64302b32-b01b-4cb2-b027-5ad59bd7ec11
+  hl-color:: green
+- Low-level mechanisms(some discussion on practical stuff)
+	- A free list contains a set of elements that describe the free space still remaining in the heap. For example, `{addr, len}`
+	  hl-page:: 195
+	  ls-type:: annotation
+	  id:: 64302ac2-a341-467e-9469-baca1e8aa7f2
+	  hl-color:: yellow
+	- Splitting and Coalescing
+	  ls-type:: annotation
+	  hl-page:: 195
+	  hl-color:: yellow
+	  id:: 64302da4-d1d5-41df-8ec8-883712d948d5
+		- split: if the request is smaller than a free block, then the allocator splits the block, take requested part and put the rest part back to free list
+		- coalesce: when returning a free chunk, the allocator looks for its nearby chunks in the free list and merge them into larger free chunk
+	- Tracking The Size Of Allocated Regions
+	  ls-type:: annotation
+	  hl-page:: 197
+	  hl-color:: yellow
+	  id:: 64302eab-54b3-4e8c-a105-cc3e8747c0f3
+		- Store some extra info in a header, which generally contains a size field and some other checking or speedup fields. Commonly, the header is placed just before the handed-out chunk of memory.
+		- When allocating, we look for a free block that fits `N+sizeof(header)` instead of merely `N`. In other words, the header is allocated along with the requested chunk of memory, though the pointer to return doesn't include header. See ((64303176-25c9-4d28-bd6e-b5b00bf74e3a)). The header's location could be calculated through pointer arithmetic `ptr - sizeof(header)`.
+		- Figure 17.2: Specific Contents Of The Header
+		  hl-page:: 197
+		  ls-type:: annotation
+		  id:: 64303176-25c9-4d28-bd6e-b5b00bf74e3a
+		  hl-color:: yellow
+	- Embedding A Free List
+	  ls-type:: annotation
+	  hl-page:: 198
+	  hl-color:: yellow
+	  id:: 643032f8-4103-4d7c-b471-fae4364ce7b5
+		- The free list's nodes resides in the chunk of memory that it is going to manage, because we cannot use stuff like `malloc` now.
+		- The implementation described in the textbook, can be concluded as: 
+		  Node structure `{size, *next}`
+		  Each node resides at the start of a contiguous free chunk of memory
+		  When allocated, the node moves to the start of the remaining free memory
+- Basic Strategies: quite boring policies
+  hl-page:: 203
+  ls-type:: annotation
+  id:: 643034f6-efa7-4f59-80a9-3561c52a5218
+  hl-color:: yellow
+	- Best Fit: pick the smallest chunk of memory that is as big or bigger than the requested size
+	  hl-page:: 203
+	  ls-type:: annotation
+	  id:: 6430350b-81b6-44db-a10d-fb0b392e957c
+	  hl-color:: yellow
+		- Try to reduce wasted space, though performance is compromised and many small free fragments are generated
+	- Worst Fit: pick the largest chunk of memory that is as big or bigger than the requested size
+	  hl-page:: 203
+	  ls-type:: annotation
+	  id:: 6430350e-5d5f-4e5a-9342-7b57874ffda8
+	  hl-color:: yellow
+		- Try to leave big chunks free and void small fragments, though costly and may not work as expected(in contrast leading to excess fragmentation)
+	- First Fit: select the first block that is big enough
+	  hl-page:: 204
+	  ls-type:: annotation
+	  id:: 64303512-4b59-4c95-b86d-62a2e1349490
+	  hl-color:: yellow
+		- No exhaustive search, thus fast.
+		- Problem: small pieces tend to accumulate at the beginning of the free list(first fit tends to take memory there), performance become worse. One alleviation approach is to use <u>address-based ordering</u>, which makes coalescing easier by keeping the list ordered by the address of free chunks.
+	- Next Fit: modified version of first fit. Try not to always take memory from the beginning.
+	  hl-page:: 204
+	  ls-type:: annotation
+	  id:: 64303515-c336-4934-987d-4ea4a29a7dfd
+	  hl-color:: yellow
+- Envision 想像,展望
+  ls-type:: annotation
+  hl-page:: 204
+  hl-color:: green
+  id:: 6430382d-9e37-412f-b983-e2a7f624954a
+- splinter 尖片, 碎片；刺
+  hl-page:: 204
+  ls-type:: annotation
+  id:: 64303831-b777-42c4-a349-d6e95ac91b25
+  hl-color:: green
+- **Segregated Lists**
+  hl-page:: 205
+  ls-type:: annotation
+  id:: 64303b17-81c8-4d92-ab80-1e48c3598403
+  hl-color:: yellow
+	- Basic Idea: If a particular application has one (or a few) popular-sized request, keep a separate list just to manage objects of that size; all other requests are forwarded to a more general memory allocator.
+	  hl-page:: 205
+	  ls-type:: annotation
+	  id:: 64303b24-47e4-4016-8111-519c599e6cca
+	  hl-color:: yellow
+	- Advantage: reduced fragmentation, faster service IF requests are of the RIGHT size
+	  Problem: how to figure out that?
+	- Real world example: `slab`.
+		- At kernel bootstrap, allocate a number of <u>object caches</u> for kernel objects that are likely to be requested frequently
+		  hl-page:: 205
+		  ls-type:: annotation
+		  id:: 64303d7c-6ac2-462c-98c9-1b61ea58a396
+		  hl-color:: yellow
+		- When a given cache is running low on free space, it requests some slabs of memory from a more general memory allocator
+		  hl-page:: 205
+		  ls-type:: annotation
+		  id:: 64303d8e-54a3-4b7f-a879-7c2533ad8b02
+		  hl-color:: yellow
+		- When the reference counts of the objects within a given slab all go to 0, the general allocator can reclaim them from the specialized allocator
+		  hl-page:: 205
+		  ls-type:: annotation
+		  id:: 64303da3-9def-447a-9cc8-08942db17f38
+		  hl-color:: yellow
+		- Free objects on the segregated lists are set in a **pre-initialized state**, in that initialization and destruction of data structures is costly
+		  hl-page:: 206
+		  ls-type:: annotation
+		  id:: 64303db7-987f-47ed-84de-c17e421159aa
+		  hl-color:: yellow
+- **Binary Buddy Allocator**: simplify coalescing
+  hl-page:: 206
+  ls-type:: annotation
+  id:: 64303dc5-8073-4659-9f39-ec6167683a7d
+  hl-color:: yellow
+	- Allocation: Recursively divide free space by 2 until a block which is MERELY big enough to accommodate the request (and a further split would be too small), is found.
+	  hl-page:: 206
+	  ls-type:: annotation
+	  id:: 64303f3a-2b0f-4106-8ab1-48e4839fe971
+	  hl-color:: yellow
+	- Deallocation: When a block is returned, check whether its buddy is free. If so, coalesce with its buddy. Recursively coalesce up the tree, and stop when a buddy is in use.
+	  hl-page:: 206
+	  ls-type:: annotation
+	  id:: 64304015-d9ff-408b-bf88-cf37a33e832d
+	  hl-color:: yellow
+	- Good quality: the address of each buddy pair only differs by a single bit, no matter the base address.
+	  hl-page:: 207
+	  ls-type:: annotation
+	  id:: 643040e1-7784-424c-9096-d3e22fddbf9e
+	  hl-color:: yellow
+- Page: fixed-sized memory unit in address space
+  hl-page:: 211
+  ls-type:: annotation
+  id:: 643044ff-fd8a-45fe-b564-f93683425ab3
+  hl-color:: yellow
+  Page frame: physical memory as an array of fixed-sized slots