Super Resolution

datapath: 对于相对粗粒度的任务调度问题，用神经网络的方法对性能还没有太大影响，但如果是内核级别的例如进程调度，拥塞控制等，神经网络方法的overhead就是非常需要减少的。 现有的方法，要么程序全部放在用户态，训练和编程比较方便，但是内核态需要调用用户态的程序，造成状态切换会导致很大开销，特别是在例如拥塞控制多个并发数据流的情况；要么程序全部放在内核态，首先内核态基本支持不了NN的训练，因为内核态不能调用用户态的库，要是把NN量化+优化之后放进内核纯做推理，也不能适应变化的数据流环境。虽然不知道数据流特征的更新频率大不大，但我觉得不能适应环境应该是训练不够充分，不是个性化场景的话retraining感觉不用很频繁，例如Nvidia的DLSS就是纯推理的部署，而且从2.0开始就是generalized的，只需要时不时根据新出的游戏更新优化一下。 LiteFlow的workflow是部署一个只作推理的模型snapshot在内核态，然后收集snapshot的输入输出，在用户态batch-wise训练，通过比较用户态模型和内核态snapshot的性能，决定是不是要更新snapshot。 对用户态模型转内核态代码，用的是量化+代码生成的方法，对于一些内核态没办法用的算子（例如tanh）就用类似泰勒级数的方法去近似，所以还要针对不同的函数做近似，非常麻烦。 snapshot更新不是原地的，而是先copy后切换，不需要中断服务。active-standby-switch

Kai Chen老师组和Xin Jin老师的工作，中了infocom21，然后扩刊TCC22。 感觉超分辨率比较适用于改善人眼观看的视频质量，不太适用于改善video analytics，很容易导致超分辨率重建的单帧比原来还模糊。 在训练超分辨率模型的时候把video analytics的模型接上，多算一个loss，这个loss还需要是特挑的small regions类的目标（比如只选单车之类的小物体，天空建筑这种就不选），但如果video analytics有多个或者一直在变怎么办？对这个领域不是很了解，感觉idea有点太简单了吧。 关于怎么确定frame-wise tail也很简单，就是看small regions占的比例有没有1%，如果没有就会产生很多误判，就属于tail frame，然而在实验结果中作用并不大。