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)