论文分享：Smartlocks: Lock Acquisition Scheduling for Self-Aware Synchronization

Motivation

针对非对称的处理器，也就是performance asymmetry（除了本身设定的如大小核心的异构系统，还有如过热降频等情况），在性能层面上讨论多核同步的可提升空间。（应该没涉及到能效层面，读完了看看能效层面能不能测试一下）

Main idea

主要通过释放锁时对下一个获得者的选择来改善性能。笼统地来说就是Lock scheduling，获取锁的顺序，找到一个符合当前架构特点下性能表现最优的处理序列。

下图为理论的提升空间，由于memory system的限制，acquire和release在slow和fast的核上消耗的时间相同（更详细的解释？），提升空间和之前像的差不多，调整运行临界区的次序后可以提高吞吐率。

（但是他没有做migration到fast的核心试试）

疑问与猜测

读前

针对smartlocks的核心思路，即选择下一个获得者，有几个问题：

1. smartlocks是如何profile每个task？如何提前知道这个task中的临界区的特性（如是否需要大量计算资源）？

   猜测有以下几种可能

   • 通过一定手段来monitor每个可能获取锁的thread，比如隔一段时间收数据。
   • 或者是需要提前运行一次积累数据。
   • 又或者像摘要里面说的，利用机器学习来预判临界区特征？

   smartlocks解决方案:

   1. 使用Heartbeats系统来采集应用的各项参数。
   2. 使用ML来调参

2. 收集这些资料是否会造成overhead？这个overhead有多少，谁来做这样一件事情？

   猜测可能会有一个单独的核心作为scheduler来收集数据，仲裁下一个获得锁的thread？

   或者释放锁的线程来做这样一件事情，这种情况下释放锁的overhead就比较大了。

   smartlocks解决方案

   1. 确实使用一个Helper Thread来RR应对所有的SL。
   2. 最好还是在单独预留的核心上运行Helper Thread。

3. 如果钦定了下一个获取锁的线程，是否会导致unfair，甚至出现饥饿？tail latency？

   猜测公平性肯定会有影响。

   饥饿应该有一定的规则来避免。

   tail latency可能又是和performace进行权衡的问题了。

   smartlocks解决方案（它实际上没解决这个问题！！！！！）

   1. smartlocks进行优化的部分是使用PR lock实现的，也就是获取锁的队列为优先队列。这样确实理论上会导致饥饿。
   2. Tail latency提都没提，也没测…

读时

1. 第一个Evaluation时做的过热降频如何用application heartbeat monitor system来模拟的？能否有方法创造过热降频的环境？

   粗略看了一下这篇paper，还比较有意思，说是比perf更好的profile应用的工具，可以看一下能不能用。

   但是针对过热降频这个场景，可能并不是非常有说服力。实际的数据中心应该不会频繁产生过热降频这个问题。

2. 第二个Evaluation说的利用cpufrequtils来控制各个核心的频率在实验室的ts850上是否还可行？

   可行！居然可以控制每个核心运行的频率。cpufrequtils不行，但是可以自己暴力改cpufreq子系统来调整频率。已经验证并开始下一步计划

3. 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)所示，均接收来自Heartbeat object的信息，放入ML Engine，用于tune合适的protocol，wait strategy和Acquisition。

设计细节

Consensus Objects

之前的saml和自己设计的CAMEL也有自动切换，是通过设计的时候使用相同的mcs lock来实现在in-place与delegation之间的切换。但是smartlock支持的lock type很多（是否真的有必要），不能通过设计来解决切换。

Smartlock通过一个Consensus Objects来解决这个问题。

主要思路是在锁释放的时候看是否要变换策略，如果不变则直接释放。如果变换，则不释放原来的锁，而是新建立一个使用新的策略的锁，并要求其他等待原来的锁在等待失败后去获取这个新的锁。

(还不清楚如何让原来等待的线程从等待中出来【已经解决】使用FUTEX_REQUEUE即可)

ML Engine

具体的实现还是有部分不清晰的。但是大致的思路已经整理清楚了。

首先最主要的目的是得到一个policy，来根据当前设置的参数 θ θ （各个线程的priority level），选择下一步的 θ θ ，这个调整过程就是Action。从Heartbeat system可以获取当前调整的Reward，不同的 θ θ 对应不同的Reward，而一个 θ θ 在不同的时间下的Reward可以平均成 η(θ) η ( θ ) 。所以需要找到 η(θ) η ( θ ) 的趋势，尽量找到 η(θ) η ( θ ) 最高点对应的 θ θ ，与之前RL学习的时候举例的 f(x) f ( x ) 最大值类似。

然而，这个特点不是已经总结出来了……如果只考虑核心运行频率的话，给更高频率的更大的优先级就行？

这么做是为了满足更多的不确定的特性吗，直接通过Reward来选择？

但是这样的问题是其他的特性能否通过调整优先级来解决？（调整优先级是否是满足其他特性的最优解？）

Evaluation

过热降频

关于如何用heartbeat system来模拟调频过程还不是很清楚，需要看一下heatbeat system的paper

主要结论与分析一致。

纵轴的rate是否标志着性能？？？或者是在cs区域里面发一次beat信号，代表更高的吞吐率？

Workload1是设置了worker0为3GHz，其他为2GHz（理论）

Workload2是设置worker3为3GHz，其他为2GHz（理论）

PR1是设置了worker0的prio高，123的prio低，PR2是设置了worker3的prio高。这个是验证了确实有改善空间。但是没清楚到底是怎么个测的，提升有多少也不清楚！！！！！

本身异构大小核

这个作者用splash测的，smartlock的性能与理论最优接近。