Review

这篇文章 Timers and time management in the Linux kernel. Part 1. 是出自 linux-insides一书中 Timers and time management 章节 Introduction 内核版本比对5.3-rc 进行了相关调整, 增加相关备注 Linux内核中的定时器和时间管理. Part 1. 介绍 这是另一篇文章，它在linux-insides一书中开启了新的篇章。前面的部分描述了系统调用概念，现在是时候开始新篇章了。正如人们可能从标题中理解的那样，本章将专门讨论Linux内核中的“定时器”和“时间管理”。当前章节的主题选择并非偶然。定时器（通常是时间管理）非常重要，并且在Linux内核中广泛使用。 Linux内核使用计时器执行各种任务，例如TCP实现中的不同超时，内核知道当前时间，调度异步函数，下一个事件中断调度和还有更多。 因此，我们将开始学习本部分中不同时间管理相关内容的实现。我们将看到不同类型的计时器以及不同的Linux内核子系统如何使用它们。与往常一样，我们将从Linux内核的最早部分开始，并完成Linux内核的初始化过程。我们已经在特殊的章节-Kernel initialization process中完成了它，它描述了Linux内核的初始化过程，但是你可能还记得我们错过了那里有些东西。其中一个是定时器的初始化。 我们开始吧。 初始化非标准PC硬件时钟 Linux内核解压缩后（更多关于此内容，您可以在内核解压缩部分中阅读）非特定代码开始在init/main.c源代码文件中工作。初始化lock validator后，初始化cgroups并设置canary值，我们可以看到setup_arch函数的调用。 你可能还记得，这个函数（定义在arch/x86/kernel/setup.c)准备/初始化特定于体系结构的东西（例如它为bss部分保留一个位置，为initrd保留一个位置，解析内核命令行以及许多其他事情）。除此之外，我们还可以找到一些时间管理相关的功能。 首先是： x86_init.timers.wallclock_init(); 我们在描述Linux内核初始化的章节中已经看到了x86_init结构。此结构包含指向不同平台的默认设置功能的指针，如 Intel MID，Intel CE4100 等x86_init结构定义在arch/x86/kernel/x86_init.c，正如您所看到的，它默认确定标准PC硬件。 我们可以看到，x86_init结构具有x86_init_ops类型，它为平台特定的设置提供了一组函数，如保留标准资源，平台特定的内存设置，中断处理程序的初始化等。这种结构如下所示： struct x86_init_ops { struct x86_init_resources resources; struct x86_init_mpparse mpparse; struct x86_init_irqs irqs; struct x86_init_oem oem; struct x86_init_paging paging; struct x86_init_timers timers; struct x86_init_iommu iommu; struct x86_init_pci pci; struct x86_hyper_init hyper; struct x86_init_acpi acpi; }; 备注： 新增以下两个成员 ...

 这篇文章 Measuring Transactional Integrity in Airbnb’s Distributed Payment Ecosystem 是出自 Airbnb Blog。 由于Airbnb的全球品牌， 其支付生态系统也异常复杂，目前支持190多个国家和全球40种货币， Airbnb与少数网关以及十多个支付机构对接，实现全球支付的覆盖。但是对接的系统中成熟度不通， 对接模式不通， 清算方式不通，而且由于其业务模式要求， 对于一笔付款需要其拆分成两笔交易， 一笔是旅行者支付到平台， 另一个笔是平台支付给房东。 在旅行者支付过程中还会涉及更改， 存款， 分期， 增值税等相对负责的交易， 在通过银行给房主付款过程中由于大多数银行采取批量模式，使得清算过程异常艰辛和漫长。 在此情况下Airbnb打造了自己新的支付网关 参考现有支付平台以及银行系统方式，新的支付网关提供商户，对账报表和流水。 但是传统的工具对账并不充分。尤其是对一些历史交易，比如撤销授权， 虽然不涉及资金但是由于是跨天交易，所以也会影响我们对账交易的范围， 数据量的增加， 从而影响系统性能。 Airbnb这里采用 Hive ， Hadoop， HDFS， Airflow， S3 系列工具包， Hive提供类似SQL的界面查询数据，可以大规模的执行map-and-reduce作业。 Hadoop提供可扩展性， 适用于大型不断增长的数据集之间比较， HDFS使我们能够定期快照事务完整性， S3可以做为经济性的数据存储。Airflow是Airbnb自己开发调度工具， 用于协调各个计算步骤从而生产相关报告。 除了保障性机制外， 其还有对应的监控机制主要是通过Druid获取香瓜事务数据， Superset生成自动报告， 通过灵活配置异常检测算法， 能够支持email/slack通知。 交易完整性分析帮助识别调整问题 并有助对系统参数进行微调。 通过以上辅助工具的在保障完整性使得财务报告准确简化运营， 深度学习分析帮助轻松监控分析问题并进行报警 。 未来的一些展望， 针对自动重试， 幂等性（idempotence guarantee ）事务跟踪进行了一些探讨。 由于本身工作原因也接触了银行收单方面的工作，接触过银行收单系统， 清算机构，第三方支付系统，在银联出现之前， 普通商户银行卡支付支付要支持多家银行，是需要分别对接各家银行的， 后来出现了银联系统， 我理解就是文中的网关，对于接触过的一些商户对于如果需要支持银行的特殊的交易如分期， 积分， 商户还是要直接对接某一个银行， 而要做跨行，由对接银行链接银联实现跨行，再后来出现了 微信支付， 支付宝支付，其实还是由银行或第三方/第四方支付机构做了这个网关的工作。 随着不断的发展还会出现新的支付方式， 新的网关，必然使得支付系统会越来越复杂。 网关是个不错的选择， 真正能做到网关级别的都是相当多的资源， 当然也会从中获取相应的利益。 前一阵facebook推出的 Libra或许是一个新的解决方案。

 这篇文章Re-Architecting the Video Gatekeeper 是出自 Netflix Technology Blog。 Netflix上的视频需要通过Title Operations 团队的策划，使其遵守的合同；字幕、配音、翻译能够提供给合适的人群；标题名称和概要可供使用和翻译；满足各个国家的成熟度等级（分级）。 Gatekeeper是Netflix的系统， 他通过汇集多个上游系统数据， 应用一些业务逻辑，为每一个国家地区每一个视频状态的输出来完成器规定任务。GateKeeper 设置这些视频是否对用户可见。为Title Operations 指出缺少的内容， 协助其工作。 现存问题： GateKeeper是一个事件驱动的系统，上游系统每个改变都会向GateKeeper发送事件，GateKeep再通过访问每个上游服务来响应事件。可能会出现下问题： I/O 瓶颈 处理延时 事件丢失 而主动扫描处理一些指定目录可以缓解这些问题， 但是增加了更多的事件。 解决方案： 使用技术：Hollow 可以看下这篇文章使用技术 Hollow ( Drew Koszewnik)，（ 2016年，是这篇的作者） Netflix Hollow是一个java库和工具集，用于将内存数据集从单个生产者传播到许多消费者，以实现高性能的只读访问。 适合小到中级数据集 Hollow 第一阶段： 使用Hollow为每个上游系统在GateKeeper增加缓存， 在指定周期内循环迭代处理所有国家地区的视频，并生成完整输出。 第二阶段： 由于第一个阶段时间片相对较长， 整个数据来自实际数据源，一个迭代周期需要很长时间。需要进一步优化。 将Hollow分为更小时间片单位， 应用程序将每次的更改通过kafka推送 Hollow，辅助周期性的整个数据源扫描来防止数据遗漏。 效果： 性能及可用性提高：消除了I/O瓶颈，提高了性能，单个上游系统故障下可以通过过时数据进行评估。 对于新投产版本，将某一个时间X的数据做为输入， 将其输出结果其与生产版本应用的输出结果进行对比（diffed ）来准确判断是否达到预期效果。对于开发，验证，部署都比之前有了很大提高， 安全性方面也比以前架构更高。 在文末也写道将在未来几个季度实现这一目标。 对于文中描述的实时推送，全量补齐方式，实施的项目中也使用过，不过是联机+批量模式：报文从一个系统A实时推送到系统B， 夜间再通过下发批量进行全量更新补全推送时丢失的信息。 对于数据重放到预发布版本，与生产版本比较执行执行结果， 来验证新版本是否达到预期效果，和我现在项目中验证方式不一样， 目前投产后通过实际交易进行验证， 如果能方便将相关数据重放到新版本进行验证，确实将减少不少验证的工作， 不过也需要相应的应用做出相关的改造才可以。

这篇文章 Scaling Appsec at Netflix 是出自 Netflix Technology Blog Netflix的 应用安全团队的主要服务对象是在云基础架构上发布应用的工程团队， Netflix安全主张：安全是每个产品团队的责任 Netflix安全团队工作主要分为三类： 应用安全运营功能：传统的AppSec活动： BUG赏金分类，测试， 威胁建模，漏洞管理，产品安全。 安全合作伙伴关系：推动整体安全改进降低风险。 应用安全自动化：构建全面的应用程序库并启动自助安全指导。 运营Appsec功能由于存在高度中断，非持续性，过去的几个月，团队进行了重组，分为自动化和合作伙伴小组两个团队。 APPsec自动化队目标是提供 一致，可操作， 自我服务，为开发提供指导。通过Spinnaker 的平台，为开发人员提供单一的视图提供相关操作， 确保应用安全。 安全工作从过去的使用一些传动的DevSecOps方法如：静态代码扫描，动态测试，反模式grep， 转变为使用自动化方式提供自助服务。 合作伙伴小组更关注于与具有高风险的工程和产品团队（例如支付工程）密切合作， 目标是确定安全风险领域， 专注于更大的战略举措从而降低风险。 团队的最终目标是退出运营职责，将工作重点放到自动化和合作伙伴两种工作模式上。

这篇文章CFI directives in assembly file (18 Jan 2017)， 是出自google 工程师Adam Langley 问题提出： 函数调用栈 : : | caller's stack | +----------------+ <----$rsp value before CALL | return address | +----------------+ <----$rsp at function entry | caller's rbp | +----------------+ <----$rbp always points here | callee's stack | 函数调用中 调用call指令时将call指令的下一条指令 return address 入栈， 其中return address存放在RIP寄存器中也就是将 RIP入栈，之后进入子函数后会将父函数的栈基地址入栈，其中父函数的栈基地保存在RBP寄存器中。 函数栈调用框架： push rbp mov rbp, rsp …. (子函数处理部分) mov rsp, rbp pop bp （leave） ...

 这篇文章 Delightful User Interfaces: Easter Eggs 是出自 Netflix Technology Blog 作者分享了网剧《Marvel’s Jessica Jones》最后一季的预告片标题页上设置的动态图特效的（Easter Eggs）的实现方法。 背景中摇摆闪烁的电灯，点击后预告片中的照片由 Jessica Jones和她的朋友,转化为Gregory Sallinge。 而这个特效没有使用视频或者webGL ， 是通过css实现的。相比视频10MB，仅需要10kb的css与722kb 图片， 背景图片由5mb压缩到108kb， 没有对效果产生影响。（这里的kb我理解是byte） 下面从三个方面介绍了CSS动态图的实现思路： 1. 开灯效果（Turning on the lights） 使用animation property 通过三张片（关闭，闪烁，开启）图片的切换实现灯泡打开的效果； 通过transform （ (rotateX, rotateX, and translate）, 及30帧图片模拟灯泡摇摆。 2. 灯管特效（Lighting: Flare and Flair） border-radius 设置影响边界, and filter: blur(80px) 设置影响区域. mix-blend-mode: 与背景颜色混合， 效果看上去很棒。 3. 背景聚焦（Bringing the background to focus） 使用 clip-path 用一个圆形对图片进行遮挡. 使用 **transition，**展示背景图片。 遇到的问题（求助StackOverflow） 1. 图片不能再某些浏览器分辨率下可以显示，解决方案 ， 将opacity过渡到父元素 不仅仅是预告片 UI工程师与设计师的合作将其实现的更为简洁而有创意。

 这篇文章 Predictive CPU isolation of containers at Netflix 是出自 Netflix Technology Blog 现存问题： 应用在云中共享空间内性能隔离。 解决方案： 操作系统级别的方案： Linux CFS（Completely Fair Scheduler）， 公平的方式将正在运行的进程分配给CPU时间片。 方案问题： 应用规模： millions of containers on thousands of machines 。 千台以上的机器上运行百万级别的容器。 组合优化： 数学中 组合优化 combinatorial optimization方法解决， 给定一组K个容器，每个容器在具有d个线程的实例上请求特定数量的CPU，目标是找到大小为（d，K）的二进制分配矩阵M， 使得每个容器获得它请求的CPU的数量。 可以使用的一些策略如： 避免将容器分散到多个NUMA socket； 尽量减少超线程 平衡L3 的缓存压力 减少容器的防止决策的操作 实现： 通过Titus是Netflix的容器平台， 管理容器 使用Linux cgroup实现CFS为每个容器操作的策略。 用户空间通过 titus-isolate Titus子系统定义三个优化时间： add：新增容器； remove：移除完成的容器， rebalance：根据CPU使用率重新评估放置策略； 每次发生时间后， 触发远程查询优化动作， 通过查询GBRT模型， 通过上下文功能 与容器关联的元数据：谁启动它，图像，内存和网络配置，应用程序名称等，以及CPU Accounting Controller（统计cgroup cpu使用情况）来预测未来10分钟内 每个CPU 95%使用率。 使用用cvxpy作为前端，将预测送入MIP（混合整数程序）求解。 服务将放置策略返回主机， 主机通过修改容器的cpusets来执行它。 后续： 支持 CPU超额预定(CPU oversubscription) 利用内核PMC事件来更直接地优化最小的缓存噪声

这篇文章 RCU part 3: the RCU API 作者： Paul E. McKenney, IBM Linux Technology Center 做为 “What is RCU”系列文章的最后一篇， 第三篇文章主要介绍了RCU API设计 基本操作 rcu_read_lock() 读者在读取由RCU保护的共享数据时使用该函数标记它进入读端临界区。 rcu_read_unlock() 该函数与rcu_read_lock配对使用，用以标记读者退出读端临界区。 synchronsize_rcu() 该函数由RCU写端调用，它将阻塞写者，直到经过grace period后，即所有的读者已经完成读端临界区，写者才可以继续下一步操作。 call_rcu() 写端调用不会阻塞 链表操作 list_for_each_entry_rcu（） 链表遍历 list_add_rcu() list_add_tail_rcu() list_del_rcu() list_replace_rcu() list_splice_init_rcu() 链表更新 作者对RCU判断是会在 the reader-writer-locking（读写锁）, reference-counting（引用技术）, and existence-guarantee constructs（存在保证结构）有更多的扩展。 更新 文章中列的API后续又更新到2010，2014，2019版本。 实验 rcu_example 是GitHub一个关于RCU调用的代码。 参考 Linux 2.6内核中新的锁机制–RCU

这篇文章 What is RCU? Part 2: Usage 作者： Paul E. McKenney, IBM Linux Technology Center ， 这篇文章主要通过与几以下几类机制的比较，深入对RCU进行了分析： RCU与读写锁机制； RCU是一种严格引用计数机制 Restricted Reference-Counting Mechanism RCU与GC机制； RCU与Existence guarantees（出自论文Gamsa等。[PDF]） RCU是一种事件等待机制； RCU优势： 性能优势：实验中与读写机制rwlock比较， 随着CPU增加RCU CPU开销没有明显增长； 死锁免疫（Deadlock Immunity）：由于读取端没有阻塞， 理论上不会有死锁。 实时性、低延时：同样也是由于RCU读端的不阻塞，使他有更出色的实时性和低延时。 RCUreader与updater同时运行 rwlock保证读者总是读到更新后的数据， 但是作者也提到了现实中类似路由表的应用， 对于旧数据影响并时不时很大，而rwlock这种机制也依赖于reader/writer优先级的设定 可以方便的替换rwlock 1 struct el { 1 struct el { 2 struct list_head list; 2 struct list_head list; 3 long key; 3 long key; 4 spinlock_t mutex; 4 spinlock_t mutex; 5 int data; 5 int data; 6 /* Other data fields */ 6 /* Other data fields */ 7 }; 7 }; 8 rwlock_t listmutex; 8 spinlock_t listmutex; 9 struct el head; 9 struct el head; 1 int search(long key, int *result) 1 int search(long key, int *result) 2 { 2 { 3 struct list_head *lp; 3 struct list_head *lp; 4 struct el *p; 4 struct el *p; 5 5 6 read_lock(&listmutex); 6 rcu_read_lock(); 7 list_for_each_entry(p, head, lp) { 7 list_for_each_entry_rcu(p, head, lp) { 8 if (p->key == key) { 8 if (p->key == key) { 9 *result = p->data; 9 *result = p->data; 10 read_unlock(&listmutex); 10 rcu_read_unlock(); 11 return 1; 11 return 1; 12 } 12 } 13 } 13 } 14 read_unlock(&listmutex); 14 rcu_read_unlock(); 15 return 0; 15 return 0; 16 } 16 } 1 int delete(long key) 1 int delete(long key) 2 { 2 { 3 struct el *p; 3 struct el *p; 4 4 5 write_lock(&listmutex); 5 spin_lock(&listmutex); 6 list_for_each_entry(p, head, lp) { 6 list_for_each_entry(p, head, lp) { 7 if (p->key == key) { 7 if (p->key == key) { 8 list_del(&p->list); 8 list_del_rcu(&p->list); 9 write_unlock(&listmutex); 9 spin_unlock(&listmutex); 10 synchronize_rcu(); 10 kfree(p); 11 kfree(p); 11 return 1; 12 return 1; 12 } 13 } 13 } 14 } 14 write_unlock(&listmutex); 15 spin_unlock(&listmutex); 15 return 0; 16 return 0; 16 } 17 } example taken from Wikipedia. 可以方便的替换rwlock 参考计数机制 Reference-Counting Mechanism：看上去和rwlock模式一致 1 rcu_read_lock(); /* acquire reference. */ 2 p = rcu_dereference(head); 3 /* do something with p. */ 4 rcu_read_unlock(); /* release reference. */ 1 spin_lock(&mylock); 2 p = head; 3 head = NULL; 4 spin_unlock(&mylock); 5 synchronize_rcu(); /* Wait for all references to be released. */ 6 kfree(p); 但是由于要求读不阻塞， 所以在与rwlock进行性能比较时大概在4个cpu时rcu与rwlock的cpu开销已经趋于一致。 ...

这篇文章What is RCU, Fundamentally? 作者： Paul E. McKenney, IBM Linux Technology Center ， Jonathan Walpole, Portland State University Department of Computer Science RCU ： read-copy-update (RCU) is a synchronization mechanism based on mutual exclusion. 对于RCU机制保护下的数据， 读数据不需要获得任何锁或者很小代价的开销就可以访问， 对于写者需要先拷贝一份副本， 然后修改，最后使用一个回调（callback）机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。 本文主要介绍RCU同步机制的三个部分： 针对插入操作的发布订阅机制； 针对删除操作的等待预先启动读者完成机制； 维护最新更新对象多个版本； 文章中以链表为例介绍了RCU处理过程： 删除情况下保持多版本： 1 struct foo { 2 struct list_head list; 3 int a; 4 int b; 5 int c; 6 }; 7 LIST_HEAD(head); 8 9 /* . . . */ 10 11 p = search(head, key); 12 if (p != NULL) { 13 list_del_rcu(&p->list); 14 synchronize_rcu(); 15 kfree(p); 16 } 找到要删除的节点 ...