IPADS Interview
This commit is contained in:
ridethepig
parent
76c76c5bfa
commit
348888fe70
@ -1,6 +1,5 @@
|
|||||||
- DONE 写一下自我介绍
|
- DONE 写一下自我介绍
|
||||||
- DONE 回顾论文，写个总结
|
- DONE 回顾论文，写个总结
|
||||||
- TODO 写自我陈述初稿
|
|
||||||
- DONE English resume refine
|
- DONE English resume refine
|
||||||
- TODO 扫描各种奖状：果酱证书、寻找robocup奖状、CET6扫描、成绩证明扫描
|
- TODO 扫描各种奖状：果酱证书、寻找robocup奖状、CET6扫描、成绩证明扫描
|
||||||
- IPADS半夜发邮件是真的离谱，不让我好好睡觉了是吧
|
- IPADS半夜发邮件是真的离谱，不让我好好睡觉了是吧
|
||||||
|
|||||||
@ -1,3 +1,9 @@
|
|||||||
- TODO 小熊思想读书会报告
|
- DONE 小熊思想读书会报告
|
||||||
- TODO 跟学长要套磁信
|
- 写了一个，还有一个
|
||||||
|
- DONE 跟学长要套磁信
|
||||||
|
- 还是自己写吧，干
|
||||||
- TODO 写一会编译器，简单的llir生成
|
- TODO 写一会编译器，简单的llir生成
|
||||||
|
- IPADS面完了，大寄特寄，写了个： ((645bac34-978f-4c48-9c0a-0e1853198a5b))
|
||||||
|
- 人生总是要继续的，明天把CUHK材料弄完
|
||||||
|
- 软件工程开课了，6.3、6.4考思政课，6.1之前交模式识别，任重道远
|
||||||
|
- 还要复习专业课，这个月打算看看数学相关的东西
|
||||||
@ -0,0 +1,5 @@
|
|||||||
|
- DONE Paper2 看完
|
||||||
|
- 废了我差不多一整天才看完
|
||||||
|
- TODO 编译器调试
|
||||||
|
- 摆烂了,明天再说
|
||||||
|
- 明天又要上课了，无聊的小熊思想，无聊的中午课，还下雨，草
|
||||||
@ -0,0 +1,456 @@
|
|||||||
|
file:: [HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf](../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf)
|
||||||
|
file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf
|
||||||
|
|
||||||
|
- Abstract
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 644b27f5-e3e1-4a24-a507-820e0abbbfd5
|
||||||
|
- Introduction
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 644b2866-2f98-49f4-a914-2d1400d47e3b
|
||||||
|
- Earlier FSs optimize for performance, but provide loose consistency guarantees
|
||||||
|
- With the speedup of modern storage devices, strong consistency can ease the pain of software programming.
|
||||||
|
- Strong consistency implies per-request sequential consistency.
|
||||||
|
- atomic modification: inode level locks
|
||||||
|
- Transaction semantics after crash recovery, all-or-none
|
||||||
|
- modern storage devices, PMEM, or non-volatile RAM
|
||||||
|
hl-page:: 2
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64511829-234d-45a3-9d1c-f50d60466704
|
||||||
|
hl-color:: yellow
|
||||||
|
- Problem with existent PM FS: complicated mechanism, write amplification
|
||||||
|
- Previous approaches are limited to atomicity unit of CPU writes.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64511979-cee9-4f46-87ba-6bbfe86bf0a4
|
||||||
|
- Problem with RTM: Block IO abort RTM; PM can be accessed as RAM, but with cache involved, also abort RTM
|
||||||
|
- enhanced asynchronous DRAM refresh (eADR)
|
||||||
|
hl-page:: 3
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64511f4c-4338-41ad-9264-263ed5a08bf4
|
||||||
|
hl-color:: yellow
|
||||||
|
- guarantee the persistence of memory writes once they become globally visible,
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6451204b-d1b8-46ed-8ec9-3a7c2d05244e
|
||||||
|
- eliminate the need for cache flush to sync with PM
|
||||||
|
- See [Detail](https://www.intel.com/content/www/us/en/developer/articles/technical/eadr-new-opportunities-for-persistent-memory-applications.html)
|
||||||
|
- Several challenges with RTM-PM
|
||||||
|
hl-page:: 3
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6451205e-7f48-43e8-8704-d221d806cc18
|
||||||
|
hl-color:: yellow
|
||||||
|
- RTM is small, while FS data transfer are generally large
|
||||||
|
- Some FS operations have long code-path, lengthening RTM section, increasing conflict abort rate
|
||||||
|
- Hardware-assisted Optimistic Persistence
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64512109-8ab0-49aa-b6a3-1524df0631ef
|
||||||
|
- eADR, HTM with cooperative locks as fallback
|
||||||
|
- HTMFS, a user-space PM file systems base on ZoFS
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64512150-84a0-4839-aef6-48bb872fa776
|
||||||
|
- Background and Motivation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6451215b-a495-4d6f-9427-f5c0c6685a28
|
||||||
|
- Persistent Memory and PM File Systems
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645124e7-37ae-404c-bc83-2ae78628767f
|
||||||
|
- 主要的点就是，PM 是 ==byte-addressable==
|
||||||
|
- Existing PMFS: The only difference would be leveraging atomic instructions to provide small updates up to a single cache line
|
||||||
|
hl-page:: 4
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64526ec1-37e2-4891-bba8-eeb07c6e02d3
|
||||||
|
hl-color:: yellow
|
||||||
|
- 作者认为现有的PMFS没啥创新，在一致性上还是用的旧东西，除了用 PM 提供的 atomic inst 来简化某些原子操作
|
||||||
|
- 2.3 Hardware Transactional Memory
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6452709d-6036-4dcd-8821-c106562565fe
|
||||||
|
- RTM的基本用法：把 critical section 用 `xbegin` 和 `xend` 包起来
|
||||||
|
hl-page:: 4
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645270e0-2153-4414-8b22-762cfc113c19
|
||||||
|
hl-color:: yellow
|
||||||
|
- Conflict aborts
|
||||||
|
hl-page:: 4
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64527149-e50e-46c8-990f-0465060f9a5a
|
||||||
|
hl-color:: yellow
|
||||||
|
- 硬件维护trx的 read set 和 write set，如果在提交之前，有别的 core 读 write set 或者写 read set，就会 abort。这些东西都在 cache 里面，维护这些也是用 cache coherence protocol
|
||||||
|
- Capacity aborts.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645271fa-ff04-4263-a2f2-d1879c1fb857
|
||||||
|
- 受到每个core本地cache比如L1，的大小的限制
|
||||||
|
- Other aborts
|
||||||
|
hl-page:: 4
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64527248-77dc-4d32-8a2b-737b7329d2e9
|
||||||
|
hl-color:: yellow
|
||||||
|
- 不兼容指令，中断（所以打IO显然不行）等东西
|
||||||
|
- 2.4 HTM in PM File Systems
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64527270-d6d5-4232-98af-c0212ef47511
|
||||||
|
- HTM的操作是在 cache 里面的，没有持久化保证，除非显式刷到内存/PM里。但是 临界区内不能刷（刷了就abort），临界区之后要是被切走就寄了（除非上锁，不如直接上锁）
|
||||||
|
- Intel 的新东西表示，它可以做到commit到cache里面就能持久化
|
||||||
|
- 3 Design
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6452774e-a951-480a-a890-322d30fe3fd0
|
||||||
|
- 直接把 FS 操作用HTM包起来不现实，因为FS的操作都很长很大
|
||||||
|
- 3.1 HOP
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645277dc-272c-4479-9d09-3f178cb77a42
|
||||||
|
- 非常自然的想法：把一个操作，或者说trx，拆成小的
|
||||||
|
- 三种操作分类：
|
||||||
|
- Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的)
|
||||||
|
- 只有 Visible Write 用 HTM 实现，Invisible 和 Read 通过别的机制来实现
|
||||||
|
- （对于一整个FS操作）首先在 RTM 外面完成所需的 read 和 invisible，然后用 RTM 完成 visible，保证它们是 atomic 的。
|
||||||
|
hl-page:: 5
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64533b91-7e2b-448b-bb4f-807cc7cb5a77
|
||||||
|
hl-color:: yellow
|
||||||
|
- RTM外面的部分不保证并发安全，用 sequence count 来解决这个问题。
|
||||||
|
hl-page:: 5
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64533cf1-c232-4630-8cf9-88cf4dbfe0c2
|
||||||
|
hl-color:: yellow
|
||||||
|
- 这东西的原型是 Linux 里面的 `seqlock` 。基本原理可以看这个。 [SeqLock中文博客](http://www.wowotech.net/kernel_synchronization/seqlock.html)。 然后这里的机制大概就是把 writer lock 给换成了 RTM，虽然细节上不是很一样
|
||||||
|
- 在读之前（RTM外）先记录 seqcount，然后进入 RTM 之后进行验证，需要保证在 RTM commit 之前这些 seqcount 都没变。如果有变化，就需要重新回到 RTM 外面的某一点重新读取
|
||||||
|
- 当然如果是 accidental abort，那么只需要重新执行RTM就可以了（就算前面读的数据炸了，反正还是要验证一次的）
|
||||||
|
- 不过有个问题它没说，就是 invisible write，它没有RTM保证不会写冲突啊？不过也有可能，它会保证 invisible 不涉及临界区？？
|
||||||
|
- Discussion of concurrency correctness.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6453427e-ce5a-4746-960b-45f9546e8b37
|
||||||
|
- Read-Read显然不冲突
|
||||||
|
- Write-Write 他说potential conflicting write 会被RTM保护起来，不过有可能会live lock掉
|
||||||
|
- Write-Read 也就是如果在RTM里面写入并且commit之前读取，会导致RTM abort
|
||||||
|
- Read-Write 的情况就比较复杂了。作者给了个图，考虑了 T1 读，同时有T2写的例子
|
||||||
|
- T2 在 T1 验证之前写：Valid fail 然后重新读。不过其实是有一个 overlap 的，图里面的第三个B点应该也会 RTM-abort
|
||||||
|
- T2 在 T1 验证之后、RTM commit 之前写：因为SeqCnt在 RTM 的 read-set 里面，写操作会修改seqcnt，所有还是会 RTM abort
|
||||||
|
- 3.2 File Operations
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534050-8459-4719-866e-612b76560e00
|
||||||
|
- 其实看 Figure 3 就行了。首先分配 shadow page，然后写 shadow page，最后用 RTM 更新指针到 shadow 上。
|
||||||
|
- 3.2.1 Data Read
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534bc6-4bde-47c6-9fa2-3a085ff59c66
|
||||||
|
- 前面也写了，用 seqcnt 机制来保证读一致性。众所周知，每个文件的inode里面都有block指针，这里给每个指针都配上了一个seqno，读的时候就用这些个东西
|
||||||
|
- 3.2.2 Data Write
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534cee-e35f-4e07-a79d-9185e36b57a2
|
||||||
|
- convert data updates to metadata updates that can be embedded in the RTM transactions.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645357b1-b9ab-456c-87b3-c1047ec5ce59
|
||||||
|
- small writes，直接塞进RTM
|
||||||
|
hl-page:: 6
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64535855-08bc-484d-951e-6cf191d5729f
|
||||||
|
hl-color:: yellow
|
||||||
|
- 大量写入，先把数据写入PM，然后再更新元数据。这时候用的就是block指针了。具体：空间分配是用的DRAM数据；（存疑？然后 shadow page 写文件数据）；最后 RTM 修改 FS 元数据，allocation 的修改这个时候才会被持久化。如果 trx 提交之前炸了，顶多就是写了点垃圾数据到空白位置罢了。
|
||||||
|
- But the blocks may have leaked after a system crash. 没看懂，为啥会leak啊？你的 alloc 数据又没落盘。
|
||||||
|
hl-stamp:: 1683184901505
|
||||||
|
hl-page:: 6
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64535ce3-9927-4e22-b2ed-9c396c3b43f2
|
||||||
|
hl-color:: red
|
||||||
|
- 不过看上去，它们这边是认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？
|
||||||
|
- 3.2.3 Allocation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d02-3d6b-4dd4-8d3f-e86767190f08
|
||||||
|
- 首先把已经分配的块放进一个 temporal allocating list 里面 （大概会在 alloc 阶段持久化？），如果commit成功就不管它，如果出事了就把这个里面的块还回去
|
||||||
|
hl-page:: 7
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64535d27-c876-4481-856e-8962e5ba9b16
|
||||||
|
hl-color:: yellow
|
||||||
|
- 在释放块的时候，也会存在中途 crash 的问题。一般是先删掉reference 然后再释放块，如果没释放完，那这个块就leak了。还是有和前面类似的疑问，这东西不是 引用一删就已经整完了吗？
|
||||||
|
- the file system crashes after a reference to a block of data has been removed (when this block of memory has not yet been freed)
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: red
|
||||||
|
id:: 64535f97-b733-4522-a2d1-dbfc8837799e
|
||||||
|
hl-stamp:: 1683185566331
|
||||||
|
- 反正感觉讲的就挺矛盾的。。。也有可能是没理解清楚？
|
||||||
|
- 3.3 Directory Operations
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d0c-9fe2-4817-b510-5d2da7d55dbf
|
||||||
|
- Figure 5 描述了目录的形式。相较于简单的UNIX FS，它在目录的inode和entry之间加了一个hash table。DirInode 指向一个 block 里面放了一个hash tab， 然后每个hash tab entry指向一组dir entries，里面才是每个目录的名字、inode
|
||||||
|
- 3.3.1 Path Walk
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d0f-1882-4633-9cd4-fce9d411aeb9
|
||||||
|
- 记录每个遍历到的entry的seqcnt，然后在RTM里面验证这些家伙
|
||||||
|
hl-page:: 7
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645385d6-70be-41ba-8697-f6bf49608834
|
||||||
|
hl-color:: yellow
|
||||||
|
- 3.3.2 Directory Updates
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d19-b941-4c04-a084-2d8a09d00883
|
||||||
|
- 不对目录的inode加锁。
|
||||||
|
- 插入或删除Dir Entry 的时候，更新 hash tab 的 bucket 的 Bseq，这样就不会冲突了（甚至还能增加一些并行性能，如果hash到不同的bucket）。不过好像直接用正在修改的目录的 Dseq 好像也可以？
|
||||||
|
- 3.4 Other File Types
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d23-1327-40ef-b58e-7c5a01559552
|
||||||
|
- 就写了一个 symlink，但是这玩意就是其他操作的组合罢了，没啥特别的东西
|
||||||
|
- 3.5 The Timestamps
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d33-2bfe-4817-a5bd-0cc3534584d7
|
||||||
|
- 三种 timestamp： Access（访问）, Modified（修改内容）, Changed（修改元数据）
|
||||||
|
- timestamp应该和其他操作写在同一个 trx 里面
|
||||||
|
- Here we observe that placing accesses and modifications to critical variables at the end of a transaction significantly reduces the probability of an abort due to conflicts.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6453916b-6fc1-4e3a-8e54-5d6c3767cf45
|
||||||
|
- 不知道为啥
|
||||||
|
- 3.6 The Special Case: Rename
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d37-b14f-4943-92c0-7bb4823fbd50
|
||||||
|
- `unlink` 和 `rmdir` 都只能删掉叶子节点，比如 rm 只能删掉空目录，所以比较简单
|
||||||
|
- `rename` 操作没有限制，会涉及到两条路径，要删一个entry再加一条entry
|
||||||
|
- 可能的死锁问题，两个并发的rename操作，涉及相同的两个目录，然后互相锁了一个。可以通过比较 lock 变量地址的方法来决定上锁顺序以避免这个问题
|
||||||
|
- 目录环问题。paper里面的例子讲的很清楚，只锁两个父目录没用，虽然不会出现一致性问题，但是会出环。所以一般会用个全局锁
|
||||||
|
- 不过 HOP 不会有这个问题。因为它的目录依赖都被记录了，只要有任何一级目录被修改，都会 validation fail 然后重来。在RTM里面会进行：validate、 removing 和 adding 三个操作
|
||||||
|
- 4 Implementation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64534d45-e498-427d-b4ef-74eaf56f7aae
|
||||||
|
- 基于 ZoFS 实现，不过我也不知道它是个啥。它分成两部分，内核里面一部分，还有用户空间的 Library。
|
||||||
|
- 坏家伙，ZoFS 是也是这帮人自己写的
|
||||||
|
- 根据权限不同，把整个 FS tree 分成不同的 zone
|
||||||
|
- Figure 7： HTMFS 分为 KernFS （大概是直接白嫖了 ZoFS 的）和自己写的 LibFS。两者通过接口 `Coffer_enlarge/shrink` 进行交互，好像 KernFS 就是个分配管理器。。。。
|
||||||
|
- 4.1 KernFS
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64539829-6f23-49fe-a860-ffa78b301acd
|
||||||
|
- 维护整个 FS 所有 zone 的信息，以及 PM 页面的属性
|
||||||
|
- 每个 zone 有一个 root page 存元数据
|
||||||
|
- 用一个 persistent 哈希表存所有的 zone ，映射 zone 的路径前缀 -> zone 的 root page 的相对地址
|
||||||
|
- User space 的请求发过来是路径，然后 KernFS 通过这个表获得 zone
|
||||||
|
- 两级分配：把很多的 pages 分给 zone，然后每个 zone 在细分管理这些 page。
|
||||||
|
- KernFS 会管理这些页面的分配状态。用两个全局的红黑树来管理 free 和 allocated 的空间，这两颗 RBT 在DRAM里面， crash 之后需要重建
|
||||||
|
- 4.2 LibFS
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6453982f-f915-40ae-a87b-f94a89af4369
|
||||||
|
- 维护每个 zone 内部的 data metadata，比如文件、目录
|
||||||
|
- 前面的 Design 都是在这里实现的
|
||||||
|
- KernFS 用 free list 管理分配，如果某个 zone 打 syscall 请求空间， KernFS 返回一个 free list 。为了不修改 kernel side， LibFS 要转换这个 list 使得能够被 HTMFS 识别
|
||||||
|
- Fallback path ：先 retry 再上锁（+ RTM 更新）最后 journaling
|
||||||
|
hl-page:: 9
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6453a07f-ca96-4a02-9cc3-1c4cb460ebee
|
||||||
|
hl-color:: yellow
|
||||||
|
- 因为有这个 fallback ，所以在 RTM 里面要先检查是不是别的进程给 lock 了，如果 lock 了就直接中止 RTM 转而去抢 lock 。
|
||||||
|
- 总结一个 RTM trick ：如果要检查什么东西，放进 RTM 里面检查，因为会加进 read-set ，这样别人改了的话就会 abort
|
||||||
|
- 4.3 Prevent RTM abort
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64539833-3b3c-451b-b550-6d33dd8ac106
|
||||||
|
- 主要原因是 page fault ，但是没法搞，所以事先 access 一下，然后再进 RTM，这样就不太容易在 RTM 里面炸了
|
||||||
|
- 偶然的 abort，直接 retry ；如果次数太多，那么就 fallback
|
||||||
|
- fallback 策略：先上锁，把 conflict abort 的可能性消除，然后再执行 HOP （或者说是RTM，就是前面的机制，这里只是不让他们冲突了）来保证崩溃一致性
|
||||||
|
- 其他原因，什么指令问题，不过那个链接挂了
|
||||||
|
- 5 Evaluation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 10
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64551435-bee3-456a-93f1-8fce14cd5771
|
||||||
|
- Performance comparison with weak consistency FS
|
||||||
|
- Application performance
|
||||||
|
- How HTM improve FS
|
||||||
|
- 5.2 Micro-benchmarks
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 10
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64551575-289f-4811-9a35-863dbe0a0eb7
|
||||||
|
- Data overwrite, low contention, first 4K of ==Different files==
|
||||||
|
- `rep-mov` 和 `sse-mov` 之间的性能差距导致 HTMFS 比 ZoFS 要慢
|
||||||
|
- 在这种情况下，cache hit rate 很高。而 `rep-mov` 的性能在这种情况下 `sse2-mov` 要好。其他的没有这种问题（因为hit）
|
||||||
|
- Data overwrite, medium contention. ==Shared file, different blocks==
|
||||||
|
- lock-free 让 HTMFS 在这种情况下显著领先，而其他的FS会随着并发数上升而性能下降
|
||||||
|
- Scalability
|
||||||
|
- Data append, low contention
|
||||||
|
- most writes miss the cache
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 10
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64551b25-e4a7-401d-b143-3d4857c4e294
|
||||||
|
- NOVA 用了 non-temporal write 和 per-core allocator，绕过 cache 直接写 PM
|
||||||
|
- HTMFS 正常先写 cache 然后再同步到 PM，miss 的时候要先读再写（占两倍带宽），导致 PM 的带宽不够了
|
||||||
|
- 如果给 HTMFS 换上 NT write ，性能会好很多
|
||||||
|
- 好像后面还是会寄掉，说是撞到了 bandwidth 上限
|
||||||
|
- Data read, low contention. Different file, a block
|
||||||
|
- all file systems scale nearly linearly （虽然HTMFS更高）
|
||||||
|
hl-page:: 10
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64551cee-971e-4759-be45-8f96ebe50a4e
|
||||||
|
hl-color:: yellow
|
||||||
|
- medium, high contention 的情况 (shared file/shared block) 差不多
|
||||||
|
- Metadata create. Create files in different directories
|
||||||
|
- 到后面不 scale 了，写入带宽不够
|
||||||
|
- NOVA 在低带宽的情况下比 HTMFS 好，因为 ZoFS 用 0 表示不存在的页面，因此在创建的时候要大量写0，而 ZoFS 没有很好的 crash consistency，如果仅用文件大小表示页面存在性，可能会导致 index 和 size 不一致
|
||||||
|
- 如果 HTMFS 删掉这个步骤（有一致性保证）变成 NZ 版本，会变快跟NOVA差不多
|
||||||
|
- Metadata create, medium. Create files in same directory.
|
||||||
|
- HTMFS scales best. 因为用的锁策略是 hash bucket
|
||||||
|
- NZ 效果前期会更好，因为消除了一些 memset
|
||||||
|
- Metadata rename, low. Rename in different dirs
|
||||||
|
- All scale linearly, HTMFS best
|
||||||
|
- Metadata rename, medium. Move to shared dir
|
||||||
|
- HTMFS much better, fine-grained OCC
|
||||||
|
- Abort rate.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64551ead-5c0e-4978-99f6-f9156e8ed99e
|
||||||
|
- 基本上没什么，到 Fall back 的就更少了
|
||||||
|
- The latency of the fallback path.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64551ef9-fa99-4c2d-8dd5-e0343042aeb6
|
||||||
|
- 3 paths, HTM, fallback, journal
|
||||||
|
- Data write 的延迟，fallback 略高于 HTM，但是 journal 远高于 两倍的HTM
|
||||||
|
- 这是因为 HTM 不是直接写 PM 的，而是写 cache （然后由 eADR 保证断电后 cache 的东西会存进 PM）。如果用直接写 PM 的方法，那么 journal 差不多是两倍
|
||||||
|
- Metadata write 的延迟几种差不多
|
||||||
|
- The performance under high abort rate. Write same file same block
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 12
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645522ec-84b5-4c1e-b029-90cb01e58587
|
||||||
|
- 测试的是 fallback 的性能，如果不是由于 memcpy 指令，HTMFS 的性能最好
|
||||||
|
- 5.3 Macro-benchmarks
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 12
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64551608-5fe1-4f1b-adfc-6d13f0226c41
|
||||||
|
- 用了两个综合测试。都是小文件读写
|
||||||
|
- Webproxy 是读为主，几种好像都差不多，HTMFS和ZoFS稍微高一点
|
||||||
|
- Varmail 是读写差不多，metadata操作多，HTMFS比较好
|
||||||
|
- 5.4 Crash Consistency Correctness
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 12
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6455164b-8ba7-4bef-b5d8-bb59aca3db00
|
||||||
|
- 论文里面写了一个例子。给一个 4KB 的 全a文件写8KB的b字符。
|
||||||
|
- 先分配一个4K空页
|
||||||
|
- fill 0-4l
|
||||||
|
- fill 4k-8k
|
||||||
|
- 把4K页更新进file index
|
||||||
|
- 更新文件大小和修改时间
|
||||||
|
- 参考状态是 all-or-nothing，也就是要么4K的a；要么8K的b同时修改时间更新、freelist减少
|
||||||
|
- 在表里面，展示了1之后crash、2之后crash、5中间crash三种 crash injection
|
||||||
|
- 5.5 Application Benchmarks
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 12
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64551652-fb9f-4e40-863f-96e5e3b40ef7
|
||||||
|
- SQLite + TPC-C
|
||||||
|
- 测吞吐量
|
||||||
|
- HTMFS/ZoFS(相当于是HTMFS的弱一致版本)性能最好，而且HTMFS相对于ZoFS的性能损失较小
|
||||||
|
- NOVA的强一致和弱一致版本之间的差距较大
|
||||||
|
- LevelDB
|
||||||
|
- 测延时
|
||||||
|
- NOVA的写延时要比HTMFS好，而读要差一些
|
||||||
|
- HTMFS和ZoFS性能几乎一致，而NOVA的弱一致版本则在写性能上有较大差距，说明一致性代价较大
|
||||||
|
- 6 Discussion
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6455165b-d35d-4532-beeb-320e353e49ce
|
||||||
|
- 6.1 Other File System Features
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64552664-0fc7-426a-bfea-94d9833ef8a8
|
||||||
|
- Compression, Deduplication, Checksum
|
||||||
|
- 这些操作基本上都没有对基本的FS操作提出特殊的要求
|
||||||
|
- 6.2 HOP in Key-Value Stores
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 14
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645526bd-e94d-4728-8180-2fcdacffc711
|
||||||
|
- HOP 机制可以迁移到 KV 数据库上
|
||||||
|
- 7 Related Work
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 14
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645516e6-8343-4d4e-9f2c-f6c13d13687d
|
||||||
|
- Persistent Transactions.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 14
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64552bd5-b559-4a64-b2e5-053111a4ebdd
|
||||||
|
- transaction semantics on PM, software programming, user-space
|
||||||
|
hl-page:: 14
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64552bf8-10f4-43e8-a07b-b5a2525d1428
|
||||||
|
hl-color:: yellow
|
||||||
|
- 也有HTM硬件设计的东西（在eADR之前）
|
||||||
|
- System Transactions and Transactional FS.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 14
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64552acd-0001-4ec1-8fc5-59187f8cfc3d
|
||||||
|
- 在OS里面用使用 HTM trx
|
||||||
|
- FS 提供 事务 接口（而HTMFS只是用事务来实现POSIX而已）
|
||||||
|
- HTM-assisted OCC
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 14
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64552b13-6de1-4f6c-9513-8dccdbe11371
|
||||||
|
- 在数据库上用HTM来提供并发性能，也有用切片的方法适应长程操作的研究
|
||||||
|
- Page fault in RTM.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 14
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64552b5a-d18e-443e-b77c-9b4700aedfea
|
||||||
|
- 前期的工作解决了该问题，通过修改RTM硬件来识别PF
|
||||||
@ -0,0 +1,741 @@
|
|||||||
|
file:: [XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf](../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf)
|
||||||
|
file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf
|
||||||
|
|
||||||
|
- ABSTRACT
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 1
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 644b281a-d7fa-4163-8e75-a39d74215bfa
|
||||||
|
- Motivation: resurgent interest in microkernel, mobile devices
|
||||||
|
- 微内核需要很多的 IPC 来保持隔离性，但是IPC 操作很慢。
|
||||||
|
- seL4 single way fast path - 468 cycles; Fuchsia - over 10k round-trip
|
||||||
|
- 相对于宏内核而言，性能差很多
|
||||||
|
- 宏内核也有 IPC 性能问题
|
||||||
|
hl-page:: 1
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645656b2-93db-4a0b-913a-1a3887c51e83
|
||||||
|
hl-color:: yellow
|
||||||
|
- Android application & user-level services
|
||||||
|
- Android Binder 机制：
|
||||||
|
- 一般而言，IPC （比如管道）要先 copy to kernel buffer 再 copy from kernel buffer
|
||||||
|
- Binder 的原理是用内存映射，两个进程映射到同一个 kernel buffer 上面，这样 sender 把数据放进去之后，receiver 就能直接用了
|
||||||
|
- 两个主要的耗时：1) domain switching, and 2) message copying
|
||||||
|
hl-page:: 1
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645657b7-afa3-47b8-af22-420c1b276d2e
|
||||||
|
hl-color:: yellow
|
||||||
|
- 上下文切换有很多指令的overhead
|
||||||
|
- 共享内存有安全问题，TOCTTOU
|
||||||
|
- 页表重映射会导致TLB 大量miss
|
||||||
|
- Previous work
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645658e6-082b-4c9c-90f1-cf172fe91328
|
||||||
|
- Software 还是要 trap
|
||||||
|
- Hardware 用 tagged memory 代替页表来减少 switch 的耗时，但是内核要大改
|
||||||
|
- The design has four goals:
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645658a9-a477-47cf-bad2-7a5b4bd91683
|
||||||
|
- 不 trap、0拷贝、kernel 小改、hardware 小改
|
||||||
|
- new primitive contains three parts
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645658bc-32e3-476b-a1b1-0f3540268e3f
|
||||||
|
- new hardware-aware abstraction, x-entry
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565a96-6cd8-467c-a29a-bd6414a4e138
|
||||||
|
- xcall-cap, for access control
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565aab-ff63-4b68-95c9-e3cb9643c9d7
|
||||||
|
- 新指令使得IPC不用陷入内核
|
||||||
|
hl-page:: 2
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64565abb-3c48-4bdd-89ad-7ef0a424bcbc
|
||||||
|
hl-color:: yellow
|
||||||
|
- new address-space mapping mechanism, relay-seg, for zero-copying message passing
|
||||||
|
hl-page:: 2
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64565ae6-b80f-4f0b-b738-fc79efc17aeb
|
||||||
|
hl-color:: yellow
|
||||||
|
- ownership transfer for TOCTOU, no TLB flush, handover in invoking chain
|
||||||
|
- synchronous IPC
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565b4b-aa86-4c99-a02a-9fff0d9d0dd0
|
||||||
|
- 解决了低 throughput 和难用的多线程模型
|
||||||
|
hl-page:: 2
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64565b70-e31c-4e24-8b1f-3511313cc0f4
|
||||||
|
hl-color:: yellow
|
||||||
|
- the migrating thread model
|
||||||
|
hl-page:: 2
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64565b7c-f2d8-49fe-b6a6-8fdc275c1e75
|
||||||
|
hl-color:: yellow
|
||||||
|
- 2 MOTIVATION
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565a29-7ced-4d34-8580-fe584783a35b
|
||||||
|
- 2.1 IPC Performance is Still Critical
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 2
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565d37-df65-4458-b1f2-838473637201
|
||||||
|
- 测试：YCSB（workload generator for benchmarking KV stores）， seL4，SQLite3
|
||||||
|
- IPC 占用了 20-40% 的时间
|
||||||
|
- IPC 过程中，大概一半的时间在复制数据，当然对于短IPC，大部分时间在 ctx switch（这个时间基本上是固定的）
|
||||||
|
- 2.2 Deconstructing IPC
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565e5f-50d5-4cc6-b9ae-e8451556bb24
|
||||||
|
- two paths of IPC in seL4
|
||||||
|
hl-page:: 3
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64565e70-647b-4f21-aaae-d94476a15c2f
|
||||||
|
hl-color:: yellow
|
||||||
|
- Fast Path and Slow Path， slow 相较于 fast 是它允许调度和中断
|
||||||
|
- Trap & Restore
|
||||||
|
hl-page:: 3
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64565ed3-701f-4502-bed8-028aefdb26df
|
||||||
|
hl-color:: yellow
|
||||||
|
- Caller trap to kernel, kernel restore to callee
|
||||||
|
- 切换是为了隔离，而隔离是因为假设进程之间的 untrust
|
||||||
|
- 可以考虑让 IPC 的两边手动管理这个切换的过程以减少开销
|
||||||
|
- 类似于什么，拥有不同地址空间的多线程？乐
|
||||||
|
- IPC Logic: major task is checking
|
||||||
|
hl-page:: 3
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64565f91-f8a0-4a82-9d9e-74097c36b04f
|
||||||
|
hl-color:: yellow
|
||||||
|
- seL4 用 `capability` 管理资源
|
||||||
|
- The kernel first fetches the caller's capability and checks its validity
|
||||||
|
hl-page:: 3
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645665f4-2ade-401d-8959-13ad94c0aaa2
|
||||||
|
hl-color:: yellow
|
||||||
|
- 然后决定 slow/fast path
|
||||||
|
- caller/callee: have different priorities, on different cores
|
||||||
|
- message size: register-size, buffer-size
|
||||||
|
- 硬件实现部分的 checking 逻辑。
|
||||||
|
- Process Switch
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565f99-ea28-4791-9a09-92fea39fabd8
|
||||||
|
- 切换到 callee， 需要操作调度队列、修改进程状态、传递msg 以及设置 AS
|
||||||
|
- To make the callee have the capability to reply, a reply_cap is added into the callee thread
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64566730-0b70-4cac-a6d6-97144d9d3462
|
||||||
|
- 这个过程中的内存访问可能会导致 cache 和 TLB miss
|
||||||
|
- Message Transfer
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565f9d-4bb9-49e9-b070-85e8b71706e0
|
||||||
|
- 3 ways according to message length
|
||||||
|
- 小于 register size ： 在 process switch 的时候复制
|
||||||
|
- 小于 IPC buffer size：用 slow path 复制
|
||||||
|
- 共享内存
|
||||||
|
- 如果直接共享内存，会导致安全和一致性问题。所以一般还是会复制一次，性能垃圾
|
||||||
|
- The message transfer dominates the IPC cycles when the message size is large.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6456684a-d557-4679-8747-044e6dfd7d04
|
||||||
|
- 3 DESIGN
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565fad-b594-408c-b404-4f04469c4fef
|
||||||
|
- 3.1 Design Overview
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565fb7-e274-465f-bf50-20dba1c8fde9
|
||||||
|
- User-level Cross Process Call
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 3
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6456687d-1f7b-4918-942f-78a3c66bdad3
|
||||||
|
- 有很多的 `x-entry` 记录可 IPC 的 procedure，然后有一个ID作为它在表里面的 Index
|
||||||
|
hl-page:: 3
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645668e1-ad08-4f89-b860-5fcbd4c57764
|
||||||
|
hl-color:: yellow
|
||||||
|
- 全局的 `x-entry-table` ，配套一个 `x-entry-table-register` 存基地址、和 `x-entry-table-size` 当界限
|
||||||
|
- `xcall-cap` 规定了每个 `x-entry` 的 IPC capabilities，这个东西是通过一个 capability bitmap 来做的
|
||||||
|
- `xcall #reg` 和 `xret` 指令
|
||||||
|
- Lightweight Message Transfer `relay-seg` 机制
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64566b0b-9fd9-474f-aeea-aa032fbca2d5
|
||||||
|
- 一个 `relay-seg` 是一块 ==物理连续== 的内存
|
||||||
|
- 内存地址翻译通过新的 reg `seg-reg` 完成，同时`seg-reg`在 caller 和 callee 之间传递，因此 callee 可以直接访问
|
||||||
|
- OS 需要保证这块物理地址不会被常规的页表映射占用
|
||||||
|
- 因为没有了页表，也就不存在 TLB miss 带来的损失
|
||||||
|
- XPC Programming Model
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64566c7e-7f1d-4cdc-86af-6f1705582814
|
||||||
|
- Both Capability & Page table
|
||||||
|
- 代码的例子说是，server 注册 `xpc_register( handler, handler_thread, max_xpc_ctx)`，然后 handler `xpc_return()`， client 先用 `alloc_relay()`构造参数再调用 `xpc_call(server_ID, xpc_arg)`。
|
||||||
|
- ~~不是很理解的是，它这里为了支持多个同时调用，给开了个线程？~~
|
||||||
|
- 大概指的是后面的 C-Stack 机制，不过这也是纯纯的猜
|
||||||
|
- 3.2 XPC Engine
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565fbe-0166-4201-9078-60168c1045c3
|
||||||
|
collapsed:: true
|
||||||
|
- xcall
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64567422-a004-4862-a497-c7ef75be73aa
|
||||||
|
- check caller's xcall-cap, reading `xcall-cap-bitmap[#reg]`
|
||||||
|
- load target `x-entry`, check valid bit
|
||||||
|
- push `linkage-record` with necessary info for ret, to `link-stack` (per-thread stack)
|
||||||
|
- load new page table pointer, set PC to `x-entry` 's entrance, with caller's `xcall-cap-reg` copied to some GPR for identification
|
||||||
|
- xret
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 4
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64567428-20ea-4554-ad8f-042aad00449d
|
||||||
|
- pop a *linkage-record* and return, with assistance of the popped data, and valid-bit checked
|
||||||
|
- xcall-cap
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645677fd-f9ea-4b7f-9fa3-50a136bc524f
|
||||||
|
- a per-thread bitmap, each index `i` indicating whether this thread is permitted to call `x-entry[i]`
|
||||||
|
- with its memory region pointed by `xcall-cap-reg`
|
||||||
|
- Link Stack
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64567819-b985-4543-80da-acf416609a79
|
||||||
|
- a per-thread stack, only accessible by kernel
|
||||||
|
- not saving GPR
|
||||||
|
- a principle that `linkage-record` should maintain information which can not be recovered by user-space.
|
||||||
|
hl-page:: 5
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6456796a-9354-48f9-b050-d0c052537225
|
||||||
|
hl-color:: yellow
|
||||||
|
- A lazy write optimization, context-switching while saving record
|
||||||
|
- XPC Engine Cache
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6456781d-cbb0-4e2e-b396-04edfa67801e
|
||||||
|
- pre-fetch `x-entry`
|
||||||
|
- software-managed cache
|
||||||
|
- hl-page:: 5
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64567a42-2b36-4ed5-8505-01f574d5740a
|
||||||
|
hl-color:: yellow
|
||||||
|
1. IPC has high temporal locality (for a single thread);
|
||||||
|
2. IPC is predictable.
|
||||||
|
- 3.3 Relay Segment
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64565fc3-b632-4cb5-949e-3f96d9ce5f2f
|
||||||
|
- relay-seg
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64567cca-6189-4008-a36e-f04ddfcdbd8c
|
||||||
|
- add a register `seg-reg` = `VA | PA | Len | Perm`
|
||||||
|
- prior to TLB, direct-map VA to PA (contiguous physical memory)
|
||||||
|
- `relay-seg` 指的是一块内存，而 `seg-reg` 表示的是一个映射
|
||||||
|
- seg-mask
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64567cc7-b245-4d66-8d32-6c9dec52f0d7
|
||||||
|
- 设计者不希望用户程序直接修改 `seg-reg` 的映射，因此加了一个`seg-mask` 用来把当前进程的 `seg-reg` 切出来一部分再传递
|
||||||
|
- 主要是用来 invoking chain 的，可能是作者认为这种情况比较常见吧
|
||||||
|
- Multiple relay-segs
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64567ccf-8fae-49c0-af3d-6082254bf2dd
|
||||||
|
- per-process memory region called `seg-list` managed by OS kernel, `seg-list-reg`
|
||||||
|
hl-page:: 5
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6457060d-d314-4136-a9e8-c26babc7888d
|
||||||
|
hl-color:: yellow
|
||||||
|
- `swapseg #reg` 指令用来更换当前的 `seg-reg` `#reg` 是目标在 `seg-list` 里面的下标；当然也可以用来 invalidate （指定无效的ID）
|
||||||
|
- Ownership of relay-seg
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64570676-1f3f-43ef-a16b-77fda80832b8
|
||||||
|
- kernel （可能是通过调度器？）保证每个 `relay-seg` 任意时刻只能在一个CPU core 上运行，也就是 owned by one thread
|
||||||
|
- 反正 paper 里面没写这东西咋实现的
|
||||||
|
- 说是能够防止 TOCTOU，大概是防止了别人瞎改 `relay-seg` 的内容吧
|
||||||
|
- Return a relay-seg
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64570679-5acf-4701-b718-f1d3b22d3df7
|
||||||
|
- 硬件保证 `seg-reg` 在 `xret` 的时候和存在 `linkage-record` 里面的是一致的
|
||||||
|
- 奇妙的安全检查机制
|
||||||
|
- emmm，它好像没说怎么创建这些东西的接口？
|
||||||
|
- 4 IMPLEMENTATION
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457122f-9508-4e29-828e-55c40dbcbfbc
|
||||||
|
- 4.1 Integration into RocketChip
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64571250-753f-4f6c-b402-926ef4594c06
|
||||||
|
- XPC Engine
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64571300-8f9d-4e88-83c9-5b37f125f5ab
|
||||||
|
- Implemented as a unit of a RochetChip core
|
||||||
|
- 新加的寄存器通过 CSR 实现，用`csrr/csrw` 读写
|
||||||
|
- **3 new instructions** are sent to the XPC engine in Execution stage. XPC engine checks the validity of an IPC and returns the callee information to the pipeline.
|
||||||
|
hl-page:: 5
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645743fe-eb6b-423d-9d5a-cbc3b7df928c
|
||||||
|
hl-color:: yellow
|
||||||
|
- 加了5个 exception
|
||||||
|
- cache 只有一个 entry 且通过软件进行管理。 prefetch 通过 `xcall` negative ID 的方式实现
|
||||||
|
- XPC Management
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 5
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645744ef-f6e9-492c-b177-d863c5d6d847
|
||||||
|
- 4 XPC objects
|
||||||
|
- global `x-entry-table`; pet-thread `link stack`; per-thread `x-call-cap` bitmap; per-address-space `relay segment list`
|
||||||
|
- 在系统启动的时候，kernel 会分配一个1024项的`x-entry-table`；而创建线程的时候，会分配8K的 `link stack` 和128B的`cap-bitmap`以及4K的`seg-list`
|
||||||
|
- During a context switch, the kernel saves and restores the per-thread objects.
|
||||||
|
hl-page:: 6
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6457467f-aedf-4029-ad71-b82f62aef329
|
||||||
|
hl-color:: yellow
|
||||||
|
- 认真的吗，只是存寄存器吧。。。
|
||||||
|
- 不过如果 entry-table 要是扩大的话，是不是cap-bitmap也要跟着扩大。。。
|
||||||
|
- 4.2 Support for Microkernels
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64571268-b744-43ab-9e30-12ae6f2451a4
|
||||||
|
- Capability
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457475b-0571-4108-b314-2538d8da6ca9
|
||||||
|
- kernel 里面实现一个新的 `grant-cap`，用来管理 thread 是否能向其他 thread grant capability
|
||||||
|
hl-page:: 6
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 645748ff-d344-4e9c-960f-c87244307900
|
||||||
|
hl-color:: yellow
|
||||||
|
- kernel 管理每个 thread 的 `grant-cap-list`，所有这个线程注册的 x-entry 都会有一个对应的条目在这个里面，说明当前线程能够把这个 x-entry 的访问权 grant 出去
|
||||||
|
- Split Thread State
|
||||||
|
hl-page:: 6
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64574760-c162-414f-a629-7bff2dbeb240
|
||||||
|
hl-color:: yellow
|
||||||
|
- 因为 x-call 切换线程不需要经过内核，因此 kernel 不知道线程已经切换了，当前的线程会被ntr，要是中途来个 page fault 就直接去世了
|
||||||
|
- separate the kernel-maintained thread state into two parts: scheduling state and runtime state
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64574e12-9654-4679-855c-b5ad8d6d2341
|
||||||
|
- scheduling state: kernel stack, priority, time slice -- sched to other thread
|
||||||
|
- runtime state: address space, capabilities -- serve this thread
|
||||||
|
- 每个线程 bind 一个 scheduling state，但是可以有多个 runtime state。kernel 可以通过 per-thread `xcall-cap-reg`来判断 runtime state，因为这玩意在 xcall 的时候会被更新
|
||||||
|
- Per-invocation C-Stack
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64574769-7ecc-49a5-9a7f-33de410ed641
|
||||||
|
- 支持一个 `x-entry` 同时被调用
|
||||||
|
- library 提供 per-invoke XPC context，包括 execution stack (C-stack) 和 local data
|
||||||
|
- 注册 x-entry 的时候会提前创建这些 context
|
||||||
|
- 在调用的时候用一个 trampoline 来选择可用的context、切换C-stack、保存local data，以及返回的时候重载数据
|
||||||
|
- 作者提到了 DoS 攻击的可能性，什么恶意进程疯狂调用来占满所有的context。
|
||||||
|
- XPC allows each server to adopt specific policies to limit the invocation from clients
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64575485-dcce-4bb6-bc9a-1f89f5f33a9d
|
||||||
|
- ((645796d4-5e4b-41ea-be08-6545fc8c26a6))
|
||||||
|
- Application Termination
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 6
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457476d-bc89-4bab-8b7e-b00e332a8c60
|
||||||
|
- 考虑 invoking chain A->B->C 上中间进程B突然挂掉了，后续的进程C可能会返回到已经终止的进程
|
||||||
|
- 在一个进程B终止的时候，kernel 检查所有的`linkage stack` 然后 invalidate 所有属于这个进程B的 entry。这样后续进程C返回的时候，就会触发 `linkage invalid exception`，由 kernel 负责 pop 这个 linkage record 并返回到更先前的进程A
|
||||||
|
- ？进程的回收也是个问题，难不成等所有的 linkage 全 pop 完了才回收吗
|
||||||
|
- 扫描所有的 linkage 效率太低，一个优化：可以在 B 终止的时候清空B的页表而不扫描所有的 linkage stack，这样返回的时候就会有 page fault 陷入 kernel 了
|
||||||
|
- 4.3 Support for Android Binder
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64571271-ee10-47f9-8c6e-97a7211b7c94
|
||||||
|
- 修改了下层的 Binder driver 和中间框架，上层API保持兼容
|
||||||
|
- Binder transaction
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645760b0-3819-4dbc-af65-e5edef87061b
|
||||||
|
- client 有一个 method code 用来指定 remote method
|
||||||
|
- client Binder object 调用 `transcat()` 进入 Binder driver，把 userspace buffer 复制到 kernel buffer，然后切到 server 在把 kernel buffer 复制到 server 的 userspace buffer。
|
||||||
|
- 2 copies，2 switches
|
||||||
|
- server Binder object 收到后执行 handler `onTransact()`
|
||||||
|
- 最后通过 driver reply 回去
|
||||||
|
- XPC 实现
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64576c77-d72b-4ade-b85a-2d8e94ba606e
|
||||||
|
- 用 Binder driver 管理 xcall-cap 和 x-entry table
|
||||||
|
- server 通过 Binder 注册的时候，framework 会 ioctl Binder driver 来新建 x-entry
|
||||||
|
- client 请求服务的时候，framework 需要 ioctl Binder driver 来设置 xcall-cap
|
||||||
|
- client 调用的时候，framework 直接用 xcall 指令并用 relay-reg 来传递 marshalled data
|
||||||
|
- Linux Kernel 需要作修改来解决前述的线程管理问题 ((64574760-c162-414f-a629-7bff2dbeb240))
|
||||||
|
- Ashmem: Anonymous Shared Memory
|
||||||
|
hl-page:: 7
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64576a2a-af0d-40e5-8f4b-3cc5010056bb
|
||||||
|
hl-color:: yellow
|
||||||
|
- file-based interface，可以通过文件描述符和其他进程共享内存
|
||||||
|
- In Android Binder, processes can share fd of an ashmem through Binder driver.
|
||||||
|
hl-page:: 7
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64576ae1-5b66-4d2a-9915-60e3505ef738
|
||||||
|
hl-color:: yellow
|
||||||
|
- XPC 实现 ashmem
|
||||||
|
- 分配：用 Binder driver 分配一个 relay-seg
|
||||||
|
- map: allocate VA and set `seg-reg`
|
||||||
|
- transfer: passing `seg-reg` in the framework during `xcall`
|
||||||
|
- 存在问题：因为前述的实现中，只有一个 `seg-reg`，因此如果想要同时用多块 ashmem，就只能通过 page fault 或者 `swapreg` 指令来切换 `seg-reg` 来实现
|
||||||
|
- 加个cache？感觉会变成新的TLB了
|
||||||
|
- 好处是不需要拷贝两次了
|
||||||
|
- 4.4 Handover along Calling Chain
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64571276-8880-47f4-addd-b03d3057b7bf
|
||||||
|
- Message Size Negotiation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64576204-098c-4a39-8ba5-9c6811c8b5d7
|
||||||
|
- 为了避免在后续调用中空间不够用，可以在一开始申请 relay-reg 的时候就预留一部分空间
|
||||||
|
- 这就需要 invoking chain 上的所有进程协商一个大小
|
||||||
|
- 不过感觉实现起来也，不是很高效的样子（除非大小是固定的，就跟RTOS一样），就看怎么设计权衡了
|
||||||
|
- Message Shrink
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 7
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645763ab-7182-4d43-abc6-2e351ecfd599
|
||||||
|
- 用 seg-mask 实现只传递一部分的 message 给 next level on the chain
|
||||||
|
- Segment Revocation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645763f1-9fe6-4c34-9392-e03a8b70ddb9
|
||||||
|
- 进程终止的时候 kernel 扫描它的 seg-list 然后把有 caller 的 relay-reg 还回去，如果是自己申请的就回收
|
||||||
|
- 5 EVALUATION
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457127a-7663-4375-9e93-f43ed6c06976
|
||||||
|
- 5.2 Microbenchmark
|
||||||
|
hl-page:: 8
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64576ea8-1038-44f5-a703-78a40e714b38
|
||||||
|
hl-color:: yellow
|
||||||
|
- Config
|
||||||
|
- Full-Ctx (save/restore full context), Partial-Ctx
|
||||||
|
- +Tagged TLB, +NonBlock Link Stack, +XPC Engine Cache
|
||||||
|
- 在一次调用中，主要有3部分开销
|
||||||
|
- 如果没开 TLB 优化，TLB miss 会占一部分
|
||||||
|
- trampoline, 保存上下文的时间
|
||||||
|
- xcall logic，主要包括 Linkage stack 和取 seg-reg 的时间，可以通过 nonblock 和 xpc cache 优化
|
||||||
|
- In the following evaluation, XPC will use “Full-Cxt” with “Nonblocking Link Stack” optimizations, to ensure the fairness of the comparison.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: blue
|
||||||
|
id:: 6457741f-f4e3-47d4-894c-f70936ceb646
|
||||||
|
- One-way Call 这里统计应该是从 client 调用 request 开始到 server 收到 onRequest
|
||||||
|
hl-page:: 8
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64577417-b2ff-4ba9-93ca-9b1a2e2cad5b
|
||||||
|
hl-color:: yellow
|
||||||
|
- 由于 XPC 不需要拷贝，所以开销很低
|
||||||
|
- 如果是普通的 seL4，耗时会随着消息长度而增长。
|
||||||
|
- 从它的图上看，slow path (32-120Byte) 的耗时甚至比 shared memory(128Byte) 要长
|
||||||
|
- Multi-core IPC
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 8
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457750c-0dc6-4bb8-b7a5-d6e7bf0c8846
|
||||||
|
- 这个cross core和same core完全一样，对照组延时就直接起飞了，好怪啊。他说是因为它的 migrating thread model 和它的优秀的locality
|
||||||
|
- 不过，TLB你说是因为你用 seg-reg 给替代了倒也合理，cache 换核心了必然要寄掉的啊（难道是L2？）
|
||||||
|
- 好像也，能理解？毕竟ICache/ITLB miss无论单核多核都是必要的，DCache/DTLB 因为不拷贝所以两种都不miss，然后那些个检查本来都是要miss一遍的。seL4因为跨核心了，所以必然是用slow path，外加因为跨核心导致的各种miss
|
||||||
|
- Moreover, a client can easily scale itself by creating several worker threads on different cores and pull the server to run on these cores.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457788c-f190-455c-ab53-4c3fc77899ba
|
||||||
|
- Other Instructions
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457776f-ef59-41ff-b236-d2a010eb8250
|
||||||
|
- 就，测了测 `xcall/xret/swapreg` 这些指令的周期，主要是访存的时延
|
||||||
|
- 5.3 OS Services
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64576ff6-bfd7-4dfa-952b-fcb3b1e82d1f
|
||||||
|
- File System
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64577b2d-646d-4b0b-a5b0-ccc79d9e24e2
|
||||||
|
- In microkernels, a file system usually includes two servers, a file system server and a block device server
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: blue
|
||||||
|
id:: 64577dca-1183-4b1c-ba74-a107ff1d3f56
|
||||||
|
hl-stamp:: 1683455439580
|
||||||
|
- 测试用了一个 Log-structured FS 和一个 ramdisk device
|
||||||
|
- 对于写操作效果比较好，因为涉及到许多要拷贝很多数据的IPC
|
||||||
|
- Network
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64577b31-ad0a-4dd2-969c-03e960791649
|
||||||
|
- Microkernel systems usually have two servers for network: one network stack server (including all network protocols) and one network device server.
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: blue
|
||||||
|
id:: 64577e7c-2b07-4986-acc6-bb7248cf9aad
|
||||||
|
- 测试移植了一个协议栈和一个 loopback driver device
|
||||||
|
- 到后面数据量大了，加速效果会降低，因为IPC的数量被摊平了（data get batched）
|
||||||
|
- 5.4 Applications
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64577000-b38c-449a-ab4b-038569490568
|
||||||
|
- SQLite3: YCSB-A and YCSB-F gain the most improvement because they have ==a lot of write/update== operations which will trigger ==frequent file access==. YSCB-C has minimal improvement since it is a ==read-only workload== and Sqlite3 has an ==in-memory cache== that can handle the read request well.
|
||||||
|
hl-page:: 9
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64577f97-4e63-431b-bd09-1d6eea865836
|
||||||
|
hl-color:: yellow
|
||||||
|
- Web Server: Most of the benefit comes from ==handover optimization==. Since in multi-server cases, the message will be transferred multiple times.
|
||||||
|
hl-page:: 9
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64577ffb-c30d-411c-bdf0-cc172f291786
|
||||||
|
hl-color:: yellow
|
||||||
|
- 5.5 Android Binder
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 9
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64577010-66d9-43ef-b304-846fb028414a
|
||||||
|
- 测试了在 WM 和 Compositor 之间的 IPC，两种方法 buffer 和 ashmem
|
||||||
|
- buffer 大小受限，因此只测了小数据；ashmem在小数据的情况下和buffer差不多
|
||||||
|
- ashmem在大数据的情况下的优化倍率就比较小了
|
||||||
|
- 同时测试了只用 relay-seg 而不用 xcall 的实现，在小数据的情况下自然是不如全套实现，大数据下差不多，因为这时候的优化主要都来自于zero-copy
|
||||||
|
- 5.6 Generality
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 10
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64577019-21ad-4ff1-b8a5-77f0be884b2c
|
||||||
|
- 用了一个周期精确的模拟器来模拟一个 in-order ARMv8-A
|
||||||
|
- use microOps to implement the functionalities of XPC engine
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 10
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64578330-b7bb-418d-b9a4-5b7e997f6b45
|
||||||
|
- 没有 cache 和 nonblocking 优化
|
||||||
|
- 因为seL4没有支持，甚至还搞了个 instruction trace 出来。。。
|
||||||
|
- 然后这模拟器还没有 TLB flush cost，甚至还专门用个什么 barrier 来模拟它
|
||||||
|
- 提升自然是有的，只不过比较抽象
|
||||||
|
- 5.7 Hardware Costs
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64577026-3083-4275-99e1-afa698407303
|
||||||
|
- 其实还行，也就多用了三四百个FF和LUT。不过我觉得就算用 verilog 重写一遍也不见得能优化多少
|
||||||
|
- 6 DISCUSSION
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457128a-0799-4b0f-aef7-1dca6ef6fdec
|
||||||
|
- 6.1 Security Analysis
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645783e4-939f-44c2-ad4f-ba6547483686
|
||||||
|
- XPC Authentication and Identification
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64579586-3e38-494b-9d6c-a070c776bc22
|
||||||
|
- xcall 指令有 xcall-cap 检查, 需要从具有对应的 grant-cap 的 server 那里请求, 类似于 nameserver
|
||||||
|
- server 可以通过 `xcall-cap-reg` 来获知调用者, 也是一种鉴权方法
|
||||||
|
- Defending TOCTTOU Attacks
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457958b-9c34-4b6e-9728-779866f4dd6f
|
||||||
|
- 保证 relay-seg 同一时间只能由一个 thread 持有 ((64570676-1f3f-43ef-a16b-77fda80832b8))
|
||||||
|
- kernel 保证 relay-seg 映射的地址和其他地址不重叠, 因此也不会被瞎改
|
||||||
|
- Fault Isolation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645796cd-b37a-4f2b-a19c-9b48c0614a91
|
||||||
|
- 由于 ((6457476d-bc89-4bab-8b7e-b00e332a8c60)) 和 ((645763f1-9fe6-4c34-9392-e03a8b70ddb9)), caller 和 callee 不会相互影响
|
||||||
|
- XPC 提供了 timeout 机制防止 callee 把 caller 给 hang 掉
|
||||||
|
- Defending DoS Attacks
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645796d4-5e4b-41ea-be08-6545fc8c26a6
|
||||||
|
- create a lot of relay-seg which requires many continuous physical memory, which may trigger external fragmentation
|
||||||
|
hl-page:: 11
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64579853-231a-4d42-aea1-c5679a27126c
|
||||||
|
hl-color:: yellow
|
||||||
|
- XPC通过将 `relay-seg`塞进进程的私有地址来解决这个问题, 至少不会让整个 OS 炸掉
|
||||||
|
- 至于耗光 context 的问题, XPC 用 credit system 来解决, 也就是检查 caller 是否有足够的 credits
|
||||||
|
- Timing Attacks
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645796da-4e3d-4dfb-b772-a0dcf97f6698
|
||||||
|
- 为啥? 类似于 meltdown 那种吗, 没想明白
|
||||||
|
- 6.2 Further Optimizations
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645783e8-7a78-4fd5-8d3a-9edd46cd164d
|
||||||
|
- Scalable xcall-cap
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64579af6-4b18-4be9-ad30-752d2e45e0b1
|
||||||
|
- 因为bitmap大小是固定的
|
||||||
|
- 可以考虑用 radix-tree, 但是访存延时会增加
|
||||||
|
- Relay Page Table
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 64579b27-3285-445e-afb7-0ffb806f686d
|
||||||
|
- 现在的 relay-seg 必须物理连续
|
||||||
|
- 可以用不同的页表来实现这个事情
|
||||||
|
- 但是 granularity 会变大, 而且ownership转移会有问题???
|
||||||
|
- 猜测是涉及到页表的加载切换
|
||||||
|
- 7 RELATED WORK
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457128f-abd3-476a-8103-2bd4ac1a8dab
|
||||||
|
- 7.1 Optimizations on Domain Switch
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 11
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645784ba-bf63-40e7-adca-1215a1f22ac7
|
||||||
|
- Software
|
||||||
|
- use caller's thread to run callee's code in callee's address space
|
||||||
|
hl-page:: 11
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 64579dee-7496-4b47-8efa-cab30ba4ceb8
|
||||||
|
hl-color:: yellow
|
||||||
|
- PPC(protected procedure call) and migrating thread
|
||||||
|
- L4的direct process switch可以减少切换代价并降低调度频率
|
||||||
|
- Hardware
|
||||||
|
- domain的概念不再是process或者是AS,而是用不同ID标识/隔离的执行单元.
|
||||||
|
- domain switch的时候不再需要trap,而是可以直接切ID就行了
|
||||||
|
- 虽然我也不知道这时候怎么搞隔离
|
||||||
|
- 多个domain可以共享地址空间,还能再省一笔
|
||||||
|
- 但是这种方法会导致软件需要大改,可移植性很差
|
||||||
|
- 也有 hybrid 方法, 或者用硬件虚拟化来做
|
||||||
|
- 7.2 Optimizations on Message Passing
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 12
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645784c3-7513-49a5-b7da-12e5d1e14455
|
||||||
|
- 软件
|
||||||
|
- 老老实实复制两遍
|
||||||
|
- 地址空间重映射,L4把待传递的消息的地址重映射到只有kernel能访问的地址上,这样就省下来一次拷贝到kernel的过程
|
||||||
|
- 不过remapping也还是有不小的overhead
|
||||||
|
- 硬件
|
||||||
|
- a hybrid memory granting mechanism combined with permission list and capability registers. Pass capability register pass memory region
|
||||||
|
hl-page:: 13
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6457a7cb-c723-4243-99ef-be1475d258d2
|
||||||
|
hl-color:: yellow
|
||||||
|
- 感觉和本文差不多? 虽说没有针对TOCTOU做防御,但是本片也不过是kernel保证一下唯一性罢了
|
||||||
|
- uses hardware capability pointers (which describe the lower and upper bounds of a memory range)
|
||||||
|
hl-page:: 13
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6457a852-cf47-4a31-924e-e7f8be729b61
|
||||||
|
hl-color:: yellow
|
||||||
|
- 问题在于他是single address space with tagged memory
|
||||||
|
- use new hardware PLB (protection look-aside buffer) to decouple the permission from the address space translation
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457a77f-0f05-4e78-b41b-b7cf0ba8fc9d
|
||||||
|
- 看上去是个可以做remapping的硬件
|
||||||
|
- 用DTU,一种类似于DMA的东西,但是对于小数据而言overhead太大
|
||||||
|
- 用什么 queue-based hardware accelerators to optimize cross-core communication
|
||||||
|
hl-page:: 13
|
||||||
|
ls-type:: annotation
|
||||||
|
id:: 6457a742-4c8d-4393-81ad-1648a830bc24
|
||||||
|
hl-color:: yellow
|
||||||
|
- 7.3 Other Related Work
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 645784c7-9b11-43e1-9c64-80ba30ebdacb
|
||||||
|
- Architectural Support for OS Performance
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457a4d4-08ea-4d2d-ac6d-050a8fc5302b
|
||||||
|
- Shared Memory for IPC
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457a4d8-2fec-4600-b1ae-0bcadc3a3237
|
||||||
|
- Asynchronous IPC
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457a4da-cf42-47db-bf8a-e37415d6750f
|
||||||
|
- Global Address Space Systems
|
||||||
|
ls-type:: annotation
|
||||||
|
hl-page:: 13
|
||||||
|
hl-color:: yellow
|
||||||
|
id:: 6457a4e2-c501-4f4e-94ef-6fd1783856f4
|
||||||
@ -5,13 +5,42 @@
|
|||||||
- TwinVisor: Hardware-isolated Confidential Virtual Machines for ARM SOSP'21
|
- TwinVisor: Hardware-isolated Confidential Virtual Machines for ARM SOSP'21
|
||||||
- Scalable Memory Protection in the Penglai Enclave OSDI'21
|
- Scalable Memory Protection in the Penglai Enclave OSDI'21
|
||||||
- XPC: Architectural Support for Secure and Efficient Cross Process Call ISCA'19
|
- XPC: Architectural Support for Secure and Efficient Cross Process Call ISCA'19
|
||||||
|
- [[hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0]]
|
||||||
- CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization SOSP'11
|
- CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization SOSP'11
|
||||||
- Serverless Computing on Heterogeneous Computers ASPLOS'22
|
- Serverless Computing on Heterogeneous Computers ASPLOS'22
|
||||||
- How to Enable Index Scheme for Reducing the Writing Cost of DNA Storage on Insertion and Deletion TECS'22
|
- How to Enable Index Scheme for Reducing the Writing Cost of DNA Storage on Insertion and Deletion TECS'22
|
||||||
- HTMFS: Strong Consistency Comes for Free with Hardware Transactional Memory in Persistent Memory File Systems FAST'22
|
- HTMFS: Strong Consistency Comes for Free with Hardware Transactional Memory in Persistent Memory File Systems FAST'22
|
||||||
|
- [[hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0]]
|
||||||
- Zero-Change Object Transmission for Distributed Big Data Analytics ATC'22
|
- Zero-Change Object Transmission for Distributed Big Data Analytics ATC'22
|
||||||
- Microsecond-scale Preemption for Concurrent GPU-accelerated DNN Inferences OSDI'22
|
- Microsecond-scale Preemption for Concurrent GPU-accelerated DNN Inferences OSDI'22
|
||||||
- No Provisioned Concurrency: Fast RDMA-codesigned Remote Fork for Serverless Computing OSDI'23
|
- No Provisioned Concurrency: Fast RDMA-codesigned Remote Fork for Serverless Computing OSDI'23
|
||||||
- Harmonizing Performance and Isolation in Microkernels with Efficient Intra-kernel Isolation and Communication ATC'20
|
- Harmonizing Performance and Isolation in Microkernels with Efficient Intra-kernel Isolation and Communication ATC'20
|
||||||
- 
|
- 过程寄录
|
||||||
- 
|
id:: 645bac34-978f-4c48-9c0a-0e1853198a5b
|
||||||
|
- 首先是发邮件，先是一个套磁信，然后它回了面试通知，然后又发了个schedule，据称最终还会有一个反馈
|
||||||
|
- 他们发邮件的时间有点阴间，有一次tmd晚上11.58给我来了一封，本来都打算睡觉了，愣是给吓醒了
|
||||||
|
- 然后是准备
|
||||||
|
- 它给了个paper list，让选两篇然后面试的时候提问。我花了差不多两次思政课看了一遍abstract，然后筛出来比较感兴趣（看得懂）的两篇。
|
||||||
|
- 看paper大概看了五天，10号面试，我从3号开始看到7号，然后9号又整理了一下
|
||||||
|
- 个人算是看的比较细，基本上所有写到的细节都看了，没写到的细节也猜了猜
|
||||||
|
- 但是事实证明，好像很多细节的没必要看，后面的evaluation扫一遍就差不多了。把基本的实现机制搞懂就行，太细节的他们也不会问（他们是盯着一个点往死里问）。
|
||||||
|
- 感觉比较重要的是深入思考，考虑一些作者没提到的东西，因为面试的时候就问这些。
|
||||||
|
- 写自我介绍、做了简单的ppt花了半天，事实证明，差不多就行了，老师估计也没听进去（大雾
|
||||||
|
- 最后是寄
|
||||||
|
- 10号下午4.10分面试，先是前面一个人拖了10分钟，实际上我20才开始，面到55结束。
|
||||||
|
- 先是简单介绍一下流程，看着老师还挺和善的，用了个他们组写的教材当背景，乐
|
||||||
|
- 自我介绍，流畅地背完了
|
||||||
|
- 然后老师估计没细听，问我有啥OS相关的经历。我说自己从头写了一个，老师很懵逼，然后问还有啥别的，我说做过xv6，然后他就问xv6了。
|
||||||
|
- 早知道不说了，直接说龙芯杯
|
||||||
|
- xv6问了个segmentation fault是怎么实现的，我tmd怎么知道是咋实现的，因为xv6里面压根没这东西啊。然后我就说，比如内存非法访问就会出page fault（然后悲剧就从这里开始了），说了一通。然后它问我怎么判断访问的是不是合法地址（我tmd真不知道啊），然后扯了一通请求分页的东西，扯完了之后我突然发现这东西的实现有很多种啊，根本没有答案。然后就瞎几把扯了一个方案，他说我懂你的思路了，于是乎结束了这个话题
|
||||||
|
- 之后是论文问答，面试的老师就是其中一篇的作者，他就接着问了。就被前面那个内存给带偏了，它先问了一个实现的机制，然后就跳到论文里没说的东西了，问我怎么做，然后我当时也没说出来一个比较好的方案，瞎几把扯了一通，看上去他没听到什么满意的东西。不过回宿舍的路上倒是想出来一个不错的方案，难绷。（总是能够在错误的时候给出正确的答案，抗压能力为负数）
|
||||||
|
- 第二篇论文的作者好像是个博士生，然后又tm从内存开始了。一开始问了一个论文里根本没提到的玩意，我说这根本没有啊，他说记错了，草，压力我是吧。同样先是问了个比较简单的实现机制，后面又开始问我论文里这东西有没有什么问题，我说原理上没有问题，但是可能效率有点低，然后它问我怎么提高，我说用什么什么树什么，然后他又说不一定啊，反正问道最后我额了半分钟就结束了这一轮对话。
|
||||||
|
- 最后他说你有啥问题没，我问了一下面试结果和招生相关的问题，就没了。
|
||||||
|
- 总体上感觉老师还算和善吧，也没太压力我什么的，就单纯的疯狂追问，问到你不会为止。我做的项目、拿的奖是一个没提，估摸着他们应该也不太懂（bushi），或者觉得太水了（大概率）。
|
||||||
|
- 我算是抱着和老师聊一聊、体验一下面试的心态去准备了这玩意（毕竟sjtu前面排着CUHK和PKU，按照去年的情况，我只要认真准备大概是能拿一个offer的，所以本来就没特别的想去），前前后后大概花了一周左右的晚上和上课的时间（剩下时间在写编译器和应付各种作业）。不过就算是这样，最后面试之前也还是挺紧张的，反反复复把论文又多看了几遍，结果就跟垃圾学校的考试一样，大部分没用到，只能说是在瞎几把卷。不过实际上面试的时候倒是不咋紧张，就跟考试一样，做着做着就适应了。
|
||||||
|
- 回想一下，答得不是很好，感觉是无了，再怎么乐观估计，也顶多是中规中矩吧。这感觉就跟之前考计网、数据结构、计基的时候差不多，考了两年半的试，这一点自觉还是有的。自我评价大概就是，这太西工大啦！纯纯的工大书呆子，发配去干苦力肯定比做研究要合适。
|
||||||
|
- 问题1：没有什么让老师特别想问的东西（比如论文或者科研经历），所以就开始扯xv6，结果扯得东西xv6偏偏还没有
|
||||||
|
- 问题2：临场反应不是很好，好像高考当时也是这么寄掉的？总是能够在错误的时候得出正确的解，但是一切都已经来不及了
|
||||||
|
- 问题3：思考的不是很深入，也不是很周全，追问到最后都寄了。脑子不行，我很抱歉
|
||||||
|
- 收获倒也是有，比如看了两篇论文，也知道了老师大概会把论文问道什么程度，要是后面夏令营再整这些东西也不会太慌。比如逼着自己把自我介绍写完了，后面再扩写成个人陈述也会轻松不少。
|
||||||
|
- 说到梦校这个东西，我大概是没有什么想法的，毕竟只要不死在东大村就行。所以寄了也就寄了吧，好像心情还挺平静的？晚上睡个好觉，就酱吧。
|
||||||
Loading…
Reference in New Issue
Block a user