Read It Never
74 subscribers
66 links
Download Telegram
Channel created
Channel photo updated
https://github.com/leandromoreira/linux-network-performance-parameters

Linux 网络参数,有大量参数原理性的解释,可以帮助理解内核相关的底层实现
https://doi.org/10.1145/3317550.3321426

在设计操作系统的年代,IO 都是很慢的,在这种情况下每次 IO 的系统调用的开销就不太重要。这种抽象在现代对 IO 的性能带来了巨大的 overhead,Linux 越来越多的加入了绕过内核,将驱动实现到用户态独占设备的 workaround(如 dpdk)。这篇讨论了将 IO 设备垂直划分的抽象方式,对容器多线程等也会更友好。
https://lwn.net/Articles/736534/
https://lwn.net/Articles/738449/

比较详细的介绍了 Linux 块设备的结构,可以帮助理解调优系统出现磁盘等块设备性能问题的原因,也可以看到在这套抽象下,块设备难以进行隔离的原因。
http://lists.llvm.org/pipermail/llvm-dev/2019-June/133308.html

A corporate-led project does not have to answer to the community, and will leave whatever bugs they introduce in place for the sake of bug-compatibility with their own software rather than fixing them.

Avoiding monoculture preserves the motivation for consensus-based standards processes rather than single-party control (see also: Chrome and what it's done to the web) and the motivation for people writing software to write to the standards rather than to a particular implementation. A big part of making that possible is clear delineation of roles between parts of the toolchain and runtime, with well-defined interface boundaries.
https://doi.org/10.1145/2901318.2901326

Linux 内核调度的 casestudy,比较全面的介绍了现代 Linux 内核调度的方法,同时几个调度的 bug 也对于在现代硬件下调度系统的复杂度有比较好的展现。
https://dl.acm.org/citation.cfm?id=3304053

降低压缩冷内存对业务服务的影响。屠龙术,比较有趣的是定义 metrics 的方法。一般认为这种内存访问是很难定义出对业务的影响指标的,本文使用单个 task 访问的冷内存块 / 访问的总内存块来定义,不过需要追踪统计在运行过程中单个 task 访问到的内存块总数(size)
https://ai.google/research/pubs/pub48630/

用户态实现业务特化的网络接口(RDMA like)与业务特化的调度来优化网络性能。相对于传统的只是 bypass NIC 到业务进程的做法来说,中心化的用户进程能更充分调度利用系统性能;而相对与修改内核网络栈的实现或者内核模块来说,进程间共享内存的成本更低,并且能以更快的迭代速度(每周)无中断的更新网络模块。就像内核调度的 casestudy 所提的,将通用的,稳定可靠优先的内核实现替换成业务特化的用户态实现可能是一类趋势。
https://doi.org/10.1145/3297858.3304053

以用户进程的方式运行 unikernel。unikernel 本身的好处是减小攻击面,减少频繁系统调用的开销,从这个角度来看把 unikernel 当作一个程序来执行像是一种退步或者折中。但是另一方面来看,由于 unikernel 本身的实现,系统调用已经被静态链接到了业务程序中,仅剩一些和外界交互的 hypercall(如 IO 等),使用 seccomp 过滤,劫持了这些 hypercall 以后,确实依然能享受到减少攻击面与减少系统调用的开销。这个实现方式有点类似 gVisor,只不过 gVisor 的内核是在业务程序外,而把 syscall 转变成 hypercall,但限制 gVisor 访问的系统调用也能达到类似的减少攻击面的效果。
https://doi.org/10.1145/3341301.3359656

Ceph 10 年心路历程。大多数的分布式文件系统都是在一个已有的文件系统上实现的用户空间文件系统,Ceph 解释了为什么这么做很难,以及为什么他们认为从 raw device 去实现是更好的方式。尤其是对于 SMR 磁盘这种设备,一个专门设计的文件系统会大幅提升 SMR 磁盘的性能。可以作为实现一个分布式文件系统大概需要考虑哪些方面的问题的参考。
http://pdxplumbers.osuosl.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf

User-level threads. Google 内部实现协程的一种方式,提供了 SwitchTo 系列的 API。老文,最近刚注意到这个 presentation 里有个细节

- The switch into kernel mode (ring0) is surprisingly inexpensive (<50ns round trip).
- Majority of the context-switching cost attributable to the complexity of the scheduling decision by a modern SMP cpu scheduler.

和传统(过时)的认知有很大区别。
https://queue.acm.org/detail.cfm?id=3212479

C is not a Low-Level language. It’s a fast PDP-11 emulator.
https://kernel.dk/io_uring.pdf

Linux 内核新加的异步 IO 接口,系统调用只用于信令控制,数据依靠 mmap 共享内存,和 RDMA (或者 Google Snap)是同一类做法。
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

fork 曾经被视为 *nix 哲学的代表(fork + exec),但是在这么多年后为了保持简单的接口,实现已经复杂到难以想象,是时候重新思考是不是真的需要 fork 这个接口了。可能是由于实现过于复杂,大多数 unikernel/unix 兼容层都没有实现 fork。
https://queue.acm.org/detail.cfm?id=1814327

The past 30 or 40 years of hardware and operating-systems development seems to have only marginally impinged on the agenda in CS departments' algorithmic analysis sections, and as far as my anecdotal evidence, it has totally failed to register in the education they provide.

问题本身不复杂,简单的改进 binary heap 尽可能减少一次查询访问到的页的数量,在高内存负载下能提升最多 10 倍的性能。
https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls

可以看一下对于系统调用开销的 evaluation,直接开销在大多数情况下占比都在 50% 甚至更少。系统调用导致的如 cache 清空等副作用,会大幅降低返回 userspace 执行的 IPC。
https://queue.acm.org/detail.cfm?id=3404974

提供一套处理线上 outage 的标准流程,基本上都是比较通用的步骤。可以防止手忙脚乱导致次生灾害,根据自己公司的情况酌情调整,原则上都比较类似。
https://ieeexplore.ieee.org/document/8543387

Checked C 的设计是在 C 原有的设计上打补丁,以最小的改动来避免某类(越界)错误的发生。在缓冲区溢出可能占了绝大多数 C 库安全问题来源的情况下,用这种方式来解决而不是从头设计一个语言是个挺有趣的思路。
https://queue.acm.org/detail.cfm?id=3415014

Using services rather than a single centralized database is like going from Newton's physics to Einstein's physics.

All data seen from a distant service is from the "past." By the time you see data from a distant service, it has been unlocked and may change. Each service has its own perspective. Its inside data provides its framework of "now." Its outside data provides its framework of the "past." My inside is not your inside, just as my outside is not your outside.