昨天晚上开了这学期第一次组会，算是活过去了233，因为要求每个人讲一下自己的思路，通知说 3 月初开题，然而我没做 ppt，也没啥思路。
毕竟关于我那个课题（关于 unikernel 的异构内存管理）的论文很少，我还去知网搜了一下，然后我笑了。（毕竟我一般去谷歌学术搜论文）
- 搜索 unikernel 关键词结果只有 5 条
- 搜索 unikernel 内存管理关键词则没有😂
然后老师又要求每个研一的同学说说自己的想法，没办法我只能借鉴之前看的一般异构内存管理的方法。
我就大概有三点想法：
- 若是能知道启动的 unikernel 的读写比例，则可以相应给其分配不同比例的内存
然后学长说这一点这是不可能的，因为你无法决定数据到底放在 DRAM 还是 NVM。 - 自己添加一个库/模块，其作用是当 unikernel 处于 idle 状态/内存利用率不高的时候将空闲内存返还给 hypervisor，然后当其内存不够的时候再向 hypervisor 申请
听完之后学长立马就说，这不是那个 ballooning 吗？（我沉默了一会，因为这就是借鉴它的思想）然后我反驳道：这个技术没被用到 unikernel 上啊。 - 开始的时候初始化一个较大内存池，由 hypervisor 管理，结合上面一点来使用。
最后老师表示最后一条好像还行，其他的还是算了吧，特别是第一个。
然后我问道，这个方面没啥资料，我也不知道该怎么做啊;3之前问同组的一个学长（我们组就我们俩做 unikernel）有没有这方面资料，他表示本来 unikernel 就没多少人做，然后内存管理就更少了，他那边也么得，我哭了…
老师：就是因为没人做，做起来才有意义啊！（学长们都偷偷笑了）
而当时我是这个表情：
最后老师还是给我了一个思路：“大页”（就我理解大概就是比传统 4k 更大的页面吧233）
瞬间感觉得救了吧，至少有了一个方向，之前完全是两眼一抹黑，看的论文基本都是讲 unikernel 安全的。
而且前两天看的 github 上的一个 unikernel 总结了所有的 unikernel 的特性、实现语言、适用平台以及现状（是否仍在维护），最后做了一个对比试验，选取的是 includeOS，将其和 Docker 进行性能比较，最后发现 unikernel 占优势的仅仅是生成的镜像大小，其余如延迟、启动时间、性能均不如 Docker（作者指出一个原因可能是 includeOS 自身存在某些 bug），可能之后我还是逃脱不了 MirageOS ，得去学 OCaml 吧。
