catfood/LogSeq
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

OSTEP chapter 17

Browse Source
This commit is contained in:
ridethepig 2023-04-08 00:31:51 +08:00
parent 628021373e
commit d0407ee179
2 changed files with 829 additions and 559 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1188
assets/ostep_1680491762166_0.edn
View File

File diff suppressed because it is too large Load Diff

200
pages/hls__ostep_1680491762166_0.md
View File

@ -509,22 +509,22 @@ file-path:: ../assets/ostep_1680491762166_0.pdf
ls-type:: annotation
id:: 642faf44-5876-46b3-acb4-b786f390716f
hl-color:: yellow
- paranoid
ls-type:: annotation
- paranoid 多疑的；偏执狂；妄想症患者
hl-page:: 142
hl-color:: green
ls-type:: annotation
id:: 642fb2f2-b9a4-48f4-b847-2b30d632db32
- rage
ls-type:: annotation
hl-color:: green
- 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 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)?
- Problem 1: variable-sized segments cause ((64302439-30a1-4724-ab5f-0d90ab8530e2))
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