最小响应内存

[snyh]

uiapp的窗口移动以及最基本的交互存在一个最小范围. 若这些内存被swap out则,必须等待swap in后用户才能感觉到"有响应". 这个最小范围称作 最小响应内存

• deepin-terminal 大概在2M
• deepin-appstore 大概在19M

由于swap-sched的机制, InActive-Apps的RSS有可能等于0 (压力非常大时完全被swap out出去).

若能寻找到一个合理的机制, 让每个uiapp都保留最小响应内存. 则整体的响应体验会再上升一个层次.

困难点:

• 最小响应内存是特定pages, 并非简单的一个值.
• 如何识别哪些内存与响应有关. (x11相关? 应该只能进程主动标识)
• 如何控制VM不要先swap out这些内存. (与VM的LRU机制有冲突)

需要调研:

1. 和直接将UI相关的so文件lock住相比, 这种机制到底能带来多大效果?
2. 如何编写工具观察某个process在被操作时哪些page被访问(以便分析page的类型)?

[snyh]

基于kernel提供的transcendent memory interface, 实现一个frontswap的backend ---> ui-backend

这样 RAM <---> ui-backend <---> RealSwapDevice
ui-backend存储在私有的RAM, 这样只要识别出UI 响应相关的page, 就能实现这种尽量不要把UI相关的page丢到swap的效果.

因此只要想办法识别 哪个page是UI相关的, 进行拦截避免直接进入RealSwapDevice即可.

[snyh]

跟踪page的访问情况可以通过

https://github.com/torvalds/linux/blob/master/Documentation/vm/pagemap.txt 以及 https://github.com/torvalds/linux/blob/master/Documentation/vm/idle_page_tracking.txt 分析得到

[snyh]

若能识别除最小内存, 或最小响应状态则对以下功能有额外帮助

1. startup notify 的自动支持. (传统方式必须应用配合)
2. 低内存下, 切换/激活应用时, 若最小内存加载过慢, 则绘制全局等待效果. (若能实现, 则完全不需要低内存提醒对话框这种设计)

[snyh]

如果绕过分析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.

[snyh]

传统算法需要考虑的情况太多，因此无法对UI进程做太多优化．(因为很多用户更加在乎非UI进程的响应)

基于kernel的frontswap，cleancache以及cgroup, 配合用户态信息，可以实现基于event的pages reclaim机制.
传统LRU是基于最近最少使用的方式，基于event是指，

1. 用户态可以以cgroup为id (CID)发送一个特定事件到kernel. 参数为page count(PG)
2. kernel根据PG以及CID, 记录此事件开始后续对应CID后续PG个page相关的操作．
3. 根据这些历史信息进行reclaim.

实现这个通用机制后，　用户态可以在UI APP触发_NET_ACTIVE_WINDOW时告知优先保证后续500个page不要被抛弃．以此事件为导向即可让UI App切换时的响应大大提高．