CFS调度器（5）-带宽控制

作者：smcdef 发布于：2018-12-22 15:07 分类：进程管理

前言

什么是带宽控制？简而言之就是控制一个用户组在给定周期时间内可以消耗CPU的时间，如果在给定的周期内消耗CPU时间超额，就限制该用户组内任务调度，直到下一个周期。限制某个进程的最大CPU使用率是否真的有必要呢？如果一个系统中仅存在一个进程，限制该进程使用CPU使用率最大50%，当进程使用率达到50%的时候，就限制该进程运行，CPU进入idle状态。看起来好像没有任何意义。但是，有时候，这正是系统管理员可能想要做的事情。如果这些进程属于仅支付了一定CPU时间的客户或者需要提供严格资源的情况，则限制进程（或进程组）可能消耗的CPU时间的最大份额是很有必要的。毕竟付多少钱享受多少服务。本文章仅讨论SCHED_NORMAL进程的CPU带宽控制（CPU bandwidth control）。

注：代码分析基于Linux 4.18.0。

阅读全文>>

标签: CFS bandwidth

评论(12) 浏览(23272)

CFS调度器（4）-PELT(per entity load tracking)

作者：smcdef 发布于：2018-12-2 15:40 分类：进程管理

为什么需要PELT？

为了让调度器更加的聪明，我们总是希望系统满足最大吞吐量同时又最大限度的降低功耗。虽然可能有些矛盾，但是现实总是这样。PELT算法是Linux 3.8合入的，那么在此之前，我们存在什么问题才引入PELT算法呢？在Linux 3.8之前，CFS以每个运行队列（runqueue，简称rq）为基础跟踪负载。但是这种方法，我们无法确定当前负载的来源。同时，即使工作负载相对稳定的情况下，在rq级别跟踪负载，其值也会产生很大变化。为了解决以上的问题，PELT算法会跟踪每个调度实体（per-scheduling entity）的负载情况。

注：代码分析基于Linux 4.18.0。

阅读全文>>

标签: PELT

评论(15) 浏览(23450)

CFS调度器（3）-组调度

作者：smcdef 发布于：2018-11-10 20:43 分类：进程管理

前言

现在的计算机基本都支持多用户登陆。如果一台计算机被两个用户A和B使用。假设用户A运行9个进程，用户B只运行1个进程。按照之前文章对CFS调度器的讲解，我们认为用户A获得90% CPU时间，用户B只获得10% CPU时间。随着用户A不停的增加运行进程，用户B可使用的CPU时间越来越少。这显然是不公平的。因此，我们引入组调度（Group Scheduling ）的概念。我们以用户组作为调度的单位，这样用户A和用户B各获得50% CPU时间。用户A中的每个进程分别获得5.5%（50%/9）CPU时间。而用户B的进程获取50% CPU时间。这也符合我们的预期。本篇文章讲解CFS组调度实现原理。

注：代码分析基于Linux 4.18.0。使能组调度需要配置CONFIG_CGROUPS和CONFIG_FAIR_GROUP_SCHED。

阅读全文>>

评论(23) 浏览(25496)

CFS调度器（2）-源码解析

作者：smcdef 发布于：2018-10-21 20:55 分类：进程管理

前言

经通过上一篇文章《CFS调度器-基本原理》，我们可以了解到CFS调度器基本工作原理。本篇文章主要集中在Linux CFS调度器源码解析。

注：文章代码分析基于Linux-4.18.0。

阅读全文>>

标签: CFS

评论(41) 浏览(28790)

CFS调度器（1）-基本原理

作者：smcdef 发布于：2018-10-7 17:36 分类：进程管理

前言

首先需要思考的问题是：什么是调度器（scheduler）？调度器的作用是什么？调度器是一个操作系统的核心部分。可以比作是CPU时间的管理员。调度器主要负责选择某些就绪的进程来执行。不同的调度器根据不同的方法挑选出最适合运行的进程。目前Linux支持的调度器就有RT scheduler、Deadline scheduler、CFS scheduler及Idle scheduler等。我想用一系列文章呈现Linux 调度器的设计原理。

注：文章代码分析基于Linux-4.18.0。

阅读全文>>

标签: CFS

评论(39) 浏览(41129)

per-entity load tracking

作者：linuxer 发布于：2018-8-18 10:27 分类：进程管理

本文分三个部分描述了3.8内核引入的PELT（per-entity load tracking）机制。第一章主要描述了PELT比per-runqueue load tracking的好处在哪里，这也是引入PELT的原因。第二章描述了具体PELT的算法，有兴趣的同学可以自行根据代码进行分析。第三章主要给出几个PELT的应用场景，在这些场景中，其他的内核子系统可以通过PELT进行更精准的控制。

本文是对https://lwn.net/Articles/531853/的翻译，有兴趣的同学可以参考原文。

阅读全文>>

标签: PELT per-entity load tracking

评论(1) 浏览(15592)

Linux中常见同步机制设计原理

作者：smcdef 发布于：2018-6-9 16:19 分类：内核同步机制

引言

今天谈谈linux中常见并发访问的保护机制设计原理。为什么要写这篇文章呢？其实想帮助自己及读者更深入的了解背后的原理（据可靠消息，锁的实现经常出现在笔试环节。既可以考察面试者对锁的原理的理解，又可以考察面试者编程技能）。我们抛开linux中汇编代码。用C语言为大家呈现背后实现的原理。同时，文章中的代码都没有考虑并发情况（例如某些操作需要原子性，或者数据需要保护等）。

阅读全文>>

标签: spin lock mutex rw_lock

评论(25) 浏览(24014)

KASLR

作者：smcdef 发布于：2018-5-6 10:00 分类：内存管理

引言

什么是KASLR？KASLR是kernel address space layout randomization的缩写，直译过来就是内核地址空间布局随机化。KASLR技术允许kernel image加载到VMALLOC区域的任何位置。当KASLR关闭的时候，kernel image都会映射到一个固定的链接地址。对于黑客来说是透明的，因此安全性得不到保证。KASLR技术可以让kernel image映射的地址相对于链接地址有个偏移。偏移地址可以通过dts设置。如果bootloader支持每次开机随机生成偏移数值，那么可以做到每次开机kernel image映射的虚拟地址都不一样。因此，对于开启KASLR的kernel来说，不同的产品的kernel image映射的地址几乎都不一样。因此在安全性上有一定的提升。

阅读全文>>

标签: kaslr

评论(29) 浏览(33627)

fixmap addresses原理

作者：smcdef 发布于：2018-4-29 20:35 分类：内存管理

引言

fixmap是一段固定地址映射。kernel预留一段虚拟地址空间。因此虚拟地址是在编译的时候确定。fixmap可以用来做什么？kernel启动初期，由于此时的kernel已经运行在虚拟地址上。因此我们访问具体的物理地址是不行的，必须建立虚拟地址和物理地址的映射，然后通过虚拟地址访问才可以。例如：dtb中包含bootloader传递过来的内存信息，我们需要解析dtb，但是我们得到的是dtb的物理地址。因此访问之前必须创建映射，创建映射又需要内存。但是由于所有的内存管理子系统还没有ready。因此我们不能使用ioremap接口创建映射。为此kernel提出fixmap的解决方案。

阅读全文>>

评论(9) 浏览(14720)

文件系统和裸块设备的page cache问题

作者：阿克曼 发布于：2018-4-28 10:16 分类：文件系统

普通文件的数据可以保存在它的地址空间中，同时直接访问块设备中此文件的块，也会将这个文件的数据保存在块设备的地址空间中。这两份缓存相互独立，kernel并不会为这种非正常访问同步两份缓存，从而避免了同步的开销。

注：本文代码基于linux-3.18.31，此版本中块缓存已经合入页缓存。

阅读全文>>

评论(9) 浏览(13441)