Open snyh opened 6 years ago
基于kernel提供的transcendent memory interface, 实现一个frontswap的backend ---> ui-backend
这样 RAM <---> ui-backend <---> RealSwapDevice ui-backend存储在私有的RAM, 这样只要识别出UI 响应相关的page, 就能实现这种尽量不要把UI相关的page丢到swap的效果.
因此只要想办法识别 哪个page是UI相关的, 进行拦截避免直接进入RealSwapDevice即可.
若能识别除最小内存, 或最小响应状态则对以下功能有额外帮助
如果绕过分析UI-App本身, 直接通过时间相关的特征,可以采用下面的形式.
记录某个UI-APP从_NET_ACTIVE_WM开始的500个PageIn,这里有很大概率是ui响应相关.只要根据这个特征进行累计分析,就可以比较好的得到实际相关页面.
每个UI-App存储500个或更多page(5004k=2M RAM), 也只需要sizeof(int)n = 8500 = 4K 字节的额外存储空间. (实际还需要2, 因为还得记录某个pageno被命中的次数)
此方案的一些细节问题:
frontswap_load(unsigned type, pgoff_t offset, struct page*p), 此时只知道type和offset, p本身是不知道的,因此在没有store前无法知道对应type:offset所属的mem_cgroup.
传统算法需要考虑的情况太多,因此无法对UI进程做太多优化.(因为很多用户更加在乎非UI进程的响应)
基于kernel的frontswap,cleancache以及cgroup, 配合用户态信息,可以实现基于event的pages reclaim机制. 传统LRU是基于最近最少使用的方式,基于event是指,
实现这个通用机制后, 用户态可以在UI APP触发_NET_ACTIVE_WINDOW时告知优先保证后续500个page不要被抛弃.以此事件为导向即可让UI App切换时的响应大大提高.
uiapp的窗口移动以及最基本的交互存在一个最小范围. 若这些内存被swap out则,必须等待swap in后用户才能感觉到"有响应". 这个最小范围称作 最小响应内存
由于swap-sched的机制, InActive-Apps的RSS有可能等于0 (压力非常大时完全被swap out出去).
若能寻找到一个合理的机制, 让每个uiapp都保留最小响应内存. 则整体的响应体验会再上升一个层次.
困难点:
需要调研: