Motivation
针对非对称的处理器，也就是performance asymmetry（除了本身设定的如大小核心的异构系统，还有如过热降频等情况），在性能层面上讨论多核同步的可提升空间。（应该没涉及到能效层面，读完了看看能效层面能不能测试一下）
Main idea
主要通过释放锁时对下一个获得者的选择来改善性能。笼统地来说就是Lock scheduling，获取锁的顺序，找到一个符合当前架构特点下性能表现最优的处理序列。
下图为理论的提升空间，由于memory system的限制，acquire和release在slow和fast的核上消耗的时间相同（更详细的解释？），提升空间和之前像的差不多，调整运行临界区的次序后可以提高吞吐率。
（但是他没有做migration到fast的核心试试）
疑问与猜测
读前
针对smartlocks的核心思路，即选择下一个获得者，有几个问题：
smartlocks是如何profile每个task？如何提前知道这个task中的临界区的特性（如是否需要大量计算资源）？
猜测有以下几种可能
- 通过一定手段来monitor每个可能获取锁的thread，比如隔一段时间收数据。
- 或者是需要提前运行一次积累数据。
- 又或者像摘要里面说的，利用机器学习来预判临界区特征？
smartlocks解决方案:
- 使用Heartbeats系统来采集应用的各项参数。
- 使用ML来调参
收集这些资料是否会造成overhead？这个overhead有多少，谁来做这样一件事情？
猜测可能会有一个单独的核心作为scheduler来收集数据，仲裁下一个获得锁的thread？
或者释放锁的线程来做这样一件事情，这种情况下释放锁的overhead就比较大了。
smartlocks解决方案
- 确实使用一个Helper Thread来RR应对所有的SL。
- 最好还是在单独预留的核心上运行Helper Thread。
如果钦定了下一个获取锁的线程，是否会导致unfair，甚至出现饥饿？tail latency？
猜测公平性肯定会有影响。
饥饿应该有一定的规则来避免。
tail latency可能又是和performace进行权衡的问题了。
smartlocks解决方案（它实际上没解决这个问题！！！！！）
- smartlocks进行优化的部分是使用PR lock实现的，也就是获取锁的队列为优先队列。这样确实理论上会导致饥饿。
- Tail latency提都没提，也没测…
读时
第一个Evaluation时做的过热降频如何用application heartbeat monitor system来模拟的？能否有方法创造过热降频的环境？
粗略看了一下这篇paper，还比较有意思，说是比perf更好的profile应用的工具，可以看一下能不能用。
但是针对过热降频这个场景，可能并不是非常有说服力。实际的数据中心应该不会频繁产生过热降频这个问题。
第二个Evaluation说的利用cpufrequtils来控制各个核心的频率在实验室的ts850上是否还可行？
可行！居然可以控制每个核心运行的频率。cpufrequtils不行，但是可以自己暴力改cpufreq子系统来调整频率。已经验证并开始下一步计划
ML的engine得出来的结果能否简单的理解是，频率更高的核心直接赋予其更高的频率？能否不使用增强学习直接根据一段时间的performance来给priority，或者是fetch到当时的core frequency后根据frequency归类的到相应的priority level？ML engine的意义是什么？
smartlocks说提供源码，comingsoon了六年github的repo还是empty的。不是很好复现……
SMARTLocks
Basic idea
- Smartlock采用独立的Helper thread来获取当前的环境信息，可以跑在单独的一个核心上，也可以和其他应用共用核心（不会导致等待切到helper才能继续的情况吗）
- 一个Helper thread可能采用RR的策略来服务所有的Smartlock。
- 每个需要调用Smartlock的thread都会有一个Smartlock Node，Smartlock Node用于与其他Smartlock Node协作，共同完成Smartlock的scheduling。
- 每个application对应一个Heartbeat object，对应一个或多个Smartlock。每个Smartlock如上图(a)
最低0.47元/天 解锁文章
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
