Buffer Sharing and Synchronization
本文的标题来自Linux Kernel 5.6.0-rc4文档, dma-buf作为一个内核子系统,它的使用场景不局限于drm “PRIME” multi-GPU支持,它主要由3个组件支撑:
本文的标题来自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 接口以及新老实现的一些细节。
之前一直有一个疑问:为什么在 drm_gpu_sheduler 的 run_job 路径里带 GFP_KERNEL 标志的内存申请可以造成死锁?, 直到了解内核内存 Pin 和 Shrink 的机制后,好像是明白了死锁的过程。
rustc
cargo
增加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:
如果先调用sched_setaffinity
将线程绑定到CPU1上,再将CPU1逻辑关闭(offline),会发生什么?在Linux系统中,要回答这个问题,先要搞清楚Linux下的3个机制:
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 |
/proc/interrupts
, /proc/cpuinfo
, top
都将看不到它
我只列出跟上面的疑问有关系的:
当关闭CPU1后,原来运行在CPU1上的进程将被移到新的CPU们上调度,具体哪个CPU是从这个进程当前的cpuset中选择,所以疑问转换成了“sched_setaffinity
对进程当前的cpuset做了什么?”