本文的标题来自Linux Kernel 5.6.0-rc4文档, dma-buf作为一个内核子系统，它的使用场景不局限于drm “PRIME” multi-GPU支持，它主要由3个组件支撑:

本文翻译 Daniel Vetter 于 2015 年 8 月 5 日发表在 LWN.net 的文章 “Atomic mode setting design overview, part 1”. 文章主要阐述了为什么要引入一个全新的 Kernel Display Driver 接口以及新老实现的一些细节。

winsys有什么用

winsys像一个桥梁，它要将GPU渲染的结果传输到窗口系统的framebuffer，由显示系统将其呈现在屏幕上。

TTM和GEM

Translation Table Maps(TTM)和Graphics Execution Manager(GEM)是Linux内核DRM子系统的两个内存管理器，前者先于后者被实现，也可以说GEM是为了解决TTM存在的一些问题才被设计出来的。下面的表格对它们两个的特点做了简单比较。

Rust Basic

• Rust的编译器 rustc
• Rust程序的构建系统或包管理器 cargo

Cargo.toml

[dependencies]

增加rand crate包后再执行构建

cargo update会做些什么

首先要了解的是在安装rustup后，在$HOME下会创建一个.cargo目录，它的目录结构大概如下

/home/luc/.cargo
|-- bin
|   |-- cargo
|   |-- cargo-clippy
|   |-- cargo-fmt
|   |-- cargo-miri
|   |-- clippy-driver
|   |-- rls
|   |-- rust-gdb
|   |-- rust-lldb
|   |-- rustc
|   |-- rustdoc
|   |-- rustfmt
|   `-- rustup
|-- env
`-- registry
    |-- cache
    |   `-- github.com-1ecc6299db9ec823
    |-- index
    |   `-- github.com-1ecc6299db9ec823
    `-- src
        `-- github.com-1ecc6299db9ec823

8 directories, 13 files

cargo update会根据工程目录下的Cargo.toml中Dependencies的版本信息下载相应版本的依赖以及依赖的依赖，cargo update后的.cargo目录结构大概如下

/home/luc/.cargo
|-- bin
|   |-- cargo
|   |-- cargo-clippy
|   |-- cargo-fmt
|   |-- cargo-miri
|   |-- clippy-driver
|   |-- rls
|   |-- rust-gdb
|   |-- rust-lldb
|   |-- rustc
|   |-- rustdoc
|   |-- rustfmt
|   `-- rustup
|-- env
`-- registry
    |-- cache
    |   `-- github.com-1ecc6299db9ec823
    |       |-- libc-0.2.98.crate
    |       |-- rand-0.3.23.crate
    |       `-- rand-0.4.6.crate
    |-- index
    |   `-- github.com-1ecc6299db9ec823
    `-- src
        `-- github.com-1ecc6299db9ec823
            |-- libc-0.2.98
            |-- rand-0.3.23
            `-- rand-0.4.6

11 directories, 16 files

References:

1. Announcing CUDA on Windows Subsystem for Linux 2

CUDA Thread Hierarchy

环境 & 版本

• Linux 5.10.16.3-microsoft-standard-WSL2 x86_64 x86_64
• Ubuntu 20.04.2 LTS
• perf version 5.10.16.3

NOTE: 如果没有特别说明，以下perf命令都在root权限下执行

A Puzzle

如果先调用sched_setaffinity将线程绑定到CPU1上，再将CPU1逻辑关闭(offline)，会发生什么？在Linux系统中，要回答这个问题，先要搞清楚Linux下的3个机制:

• CPU hotplug
• cpuset
• scheduling affinity

CPU hotplug

CPU hotplug的意思是, Linux允许Logically Shutdown和Bring Up CPU, 用户可以通过sysfs接口操作

1

echo 0 > /sys/devices/system/cpu/cpu1/online

1

echo 1 > /sys/devices/system/cpu/cpu1/online

What if the cpu is shutdown

/proc/interrupts, /proc/cpuinfo, top都将看不到它

What happened if the cpu is shutdown

我只列出跟上面的疑问有关系的:

• All processes are migrated away from this outgoing CPU to new CPUs. The new CPU is chosen from each process’ current cpuset, which may be a subset of all online CPUs.

当关闭CPU1后，原来运行在CPU1上的进程将被移到新的CPU们上调度，具体哪个CPU是从这个进程当前的cpuset中选择，所以疑问转换成了“sched_setaffinity对进程当前的cpuset做了什么？”

cpuset

udev

udev是Linux系统管理/dev的内核组件，它负责在系统运行时动态的创建和删除/dev下的设备文件(节点)。

• 当设备被检测到时创建设备文件
• 当设备被移除时删除设备文件
• /etc/udev/rules.d允许用户自定义设备文件的权限，路径和符号链接

udev显然是支持Hotplug, 而且保证/dev下的设备节点是实时更新的。而且它强大的用户自定义行为非常灵活。但它的问题是：

• 用户自定义规则的存在让应用程序很难确定特定的设备文件和设备类型
• 同一类型的多个设备，设备文件的创建顺序是不确定的

Reference

libudev and sysfs tutorial