SLUB DEBUG原理

作者：smcdef 发布于：2018-2-22 21:49 分类：内存管理

1. 前言
在工作中，经常会遇到由于越界导致的各种奇怪的问题。为什么越界访问导致的问题很奇怪呢？在工作差不多半年的时间里我就遇到了很多越界访问导致的问题（不得不吐槽下IC厂商提供的driver，总是隐藏着bug）。比如说越界访问导致的死机问题，这种问题的出现一般需要长时间测试才能发现，而且发现的时候即使有panic log。你也没什么头绪。这是为什么呢？

阅读全文>>

标签: slub 内存管理

评论(18) 浏览(42144)

图解slub

作者：smcdef 发布于：2018-2-22 21:02 分类：内存管理

1. 前言

在Linux中，伙伴系统（buddy system）是以页为单位管理和分配内存。但是现实的需求却以字节为单位，假如我们需要申请20Bytes，总不能分配一页吧！那岂不是严重浪费内存。那么该如何分配呢？slab分配器就应运而生了，专为小内存分配而生。slab分配器分配内存以Byte为单位。但是slab分配器并没有脱离伙伴系统，而是基于伙伴系统分配的大内存进一步细分成小内存分配。

前段时间学习了下slab分配器工作原理。因为自己本身是做手机的，发现现在好像都在使用slub分配器，想想还是再研究一下slub的工作原理。之前看了代码，感觉挺多数据结构和成员的。成员的意思是什么？数据结构之间的关系是什么？不知道你是否感觉云里雾里。既然代码阅读起来晦涩难懂，如果有精美的配图，不知是否有助于阁下理解slub的来龙去脉呢？我想表达的意思就是文章图多，图多，图多。我们只说原理，尽量不看代码。因为所有代码中包含的内容我都会用图来说明。你感兴趣绝对有助于你看代码。

说明：slub是slab中的一种，slab也是slab中的一种。有时候用slab来统称slab, slub和slob。slab, slub和slob仅仅是分配内存策略不同。本篇文章中说的是slub分配器工作的原理。但是针对分配器管理的内存，下文统称为slab缓存池。所以文章中slub和slab会混用，表示同一个意思。

注：文章代码分析基于linux-4.15.0-rc3。

阅读全文>>

标签: slub 内存管理

评论(18) 浏览(56438)

Deadline调度器之（二）：细节和使用方法

作者：linuxer 发布于：2018-2-22 18:23 分类：进程管理

Linux内核的DL调度器是一个全局EDF调度器，它主要针对有deadline限制的sporadic任务。注意：这些术语已经在本系列文章的第一部分中说明了，这里不再赘述。在这本文中，我们将一起来看看Linux DL调度器的细节以及如何使用它。另外，本文对应的英文原文是https://lwn.net/Articles/743946/，感谢lwn和Daniel Bristot de Oliveira的分享。

阅读全文>>

标签: scheduler Deadline

评论(3) 浏览(23574)

KASAN实现原理

作者：smcdef 发布于：2018-2-11 22:32 分类：内存管理

1. 前言

KASAN是一个动态检测内存错误的工具。KASAN可以检测全局变量、栈、堆分配的内存发生越界访问等问题。功能比SLUB DEBUG功能齐全并且支持实时检测。越界访问的严重性和危害性通过我之前的文章（SLUB DEBUG技术）应该有所了解。正是由于SLUB DEBUG缺陷，因此我们需要一种更加强大的检测工具。难道你不想吗？KASAN就是其中一种。KASAN的使用真的很简单。但是我是一个追求刨根问底的人。仅仅止步于使用的层面，我是不愿意的，只有更清楚的了解实现原理才能更加熟练的使用工具。不只是KASAN，其他方面我也是这么认为。但是，说实话，写这篇文章是有点底气不足的。因为从我查阅的资料来说，国内没有一篇文章说KASAN的工作原理，国外也是没有什么文章关注KASAN的原理。大家好像都在说How to use。由于本人水平有限，就根据现有的资料以及自己阅读代码揣摩其中的意思。本文章作为抛准引玉，如果有不合理的地方还请指正。
注：文章代码分析基于linux-4.15.0-rc3。

阅读全文>>

标签: KASAN原理

评论(32) 浏览(70744)

deadline调度器之（一）：原理

作者：linuxer 发布于：2018-1-31 19:20 分类：进程管理

    关于deadline调度器的文档有两篇，本篇简单介绍了实时调度及其背后的一些理论。另外一篇将专门讨论Linux系统中的Deadline调度器。另外，本文主要的框架和思想来自Deadline scheduling part 1 — overview and theory，但经过作者的翻译、整理和演绎。

阅读全文>>

标签: deadline调度器

评论(0) 浏览(29363)

Meltdown论文翻译

作者：linuxer 发布于：2018-1-19 20:18 分类：基础学科

本文是作者阅读meltdown论文随手翻译的一些文字记录，希望能帮助到那些对meltdown感兴趣，但英文不是那么好的同学。水平有限，欢迎指正。

阅读全文>>

标签: Meltdown

评论(3) 浏览(19477)

统一设备模型：kobj、kset分析

作者：callme_friend 发布于：2018-1-9 18:37 分类：统一设备模型

kobj/kset作为统一设备模型的基础，到底提供了哪些功能，在具体应用过程中，如device、bus甚至platform_device等是如何使用kobj/kset的，这是本文的主要阐述内容。

阅读全文>>

标签: kset kobj

评论(6) 浏览(26025)

O(n)、O(1)和CFS调度器

作者：linuxer 发布于：2018-1-8 19:19 分类：进程管理

随着内核版本的演进，其源代码的膨胀速度也在递增，这让Linux的学习曲线变得越来越陡峭了。这对初识内核的同学而言当然不是什么好事情，满腔热情很容易被当头浇灭。我有一个循序渐进的方法，那就是先不要看最新的内核，首先找到一个古老版本的内核（一般都会比较简单），将其吃透，然后一点点的迭代，理解每个版本变更背后的缘由和目的，最终推进到最新内核版本。

本文就是从2.4时代的任务调度器开始，详细描述其实现并慢慢向前递进。当然，为了更好的理解Linux调度器设计和实现，我们在第二章给出了一些通用的概念。之后，我们会在第四章讲述O（1）调度器如何改进并提升调度器性能。真正有划时代意义的是CFS调度器，在2.6.23版本的内核中并入主线。它的设计思想是那么的眩目，即便是目前最新的内核中，完全公平的设计思想仍然没有太大变化，这些我们会在第六章描述。第五章是关于公平调度思想的引入，通过这一章可以了解Con Kolivas的RSDL调度器，它是开启公平调度的先锋，通过这一章的铺垫，我们可以更顺畅的理解CFS。

阅读全文>>

标签: O(n) O(1) CFS scheduler

评论(17) 浏览(28143)

中断唤醒系统流程

作者：smcdef 发布于：2018-1-1 17:03 分类：中断子系统

1) 设备唤醒cpu之后是立即跳转中断向量表指定的位置吗？如果不是，那么是什么时候才会跳转呢？

2) 已经跳转到中断服务函数开始执行代码，后续就会调用你注册的中断handle 代码吗？如果不是，那中断服务函数做什么准备呢？而你注册的中断handle又会在什么时候才开始执行呢？
3) 假如register_thread_irq方式注册的threaded irq中调用msleep(1000)，睡眠1秒，请问系统此时会继续睡下去而没调度回来吗？因此导致msleep后续的操作没有执行。
4) 如果在注册的中断handle中把主要的操作都放在delayed work中，然后queue delayed work，work延时1秒执行，请问系统此时会继续睡下去而没调度delayed work 吗？因此导致delayed work 中的操作没有执行呢？
5) 如果4)成立的话，我们该如何编程避免这个问题呢？
好了，本片文章就为你解答所有的疑问。
注：文章代码分析基于linux-4.15.0-rc3。

阅读全文>>

标签: 电源管理 中断处理 中断子系统 中断唤醒

评论(22) 浏览(43736)

USB-C(USB Type-C)规范的简单介绍和分析

作者：wowo 发布于：2017-12-18 16:18 分类：USB

从1996年1月USB1.0正式发布至今（2017年9月 USB3.2发布），USB已经走过了21个年头。在这21年的时间了，USB标准化组织（USB Implementers Forum，USB-IF）折腾出来了各式各样、五花八门的接口形态：Type A、Type A SuperSpeed、Type B、Type B SuperSpeed、Mini-A、Mini-B、Micro-A、Micro-B、Micro-B SuperSpeed、Type C等等。

另外，USB接口主要由插座（Receptacle）、插头（Plug）和线缆（Cable）三部分组成，再叠加上这些奇奇怪怪的规范，灾难就发生了：

A产品喜欢用Type A的插座，B产品偏偏喜欢Type B，连接它们的线缆就悲剧了，只能变成A-to-B的了。以此类推，A-to-A、B-to-B、A-to-MicroA、等等，于是我们的抽屉就挤满了各种不明用途的USB线……

好吧，吐槽时间结束，因为本文的主角不是过去的那些奇奇怪怪的接口，而是最新的、红到发紫的USB-C（也称作USB Type C）规范。提起typec，它还真和它的A、B前辈们不太一样：

因为它有自己独立的、自行演化的规范文件----USB Type-C Specification（2014年发8月布1.0版本，2017年7月发布1.3版本）。而前辈们就没有这样的待遇了，它们都依附于具体的USB规范（USB 1.0、USB 1.1、USB 2.0、等等）。

为什么会这样的呢？当然是因为它有独特之处了，具体请参考本文后续的描述。

阅读全文>>

标签: Power USB typec type-c 3.1 pd

评论(17) 浏览(58984)