泰晓资讯·2月 / 第三期 / 2020

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

一种用于嵌入式环境的 Python 实现：“Snek”

Keith Packard is no stranger to the linux.conf.au stage; he has spoken on a wide variety of topics since he started going to the conference in 2004 (which was held in Adelaide, where organizers apparently had a lot of ice cream for attendees). One of his talks at this year’s conference was on an education-focused project that he has been working on for around a year: a version of Python called “Snek” targeting embedded processors. He gave a look at some of the history of his work with 10-12 year-old students that led to the development of Snek as well as some plans for the language—and hardware to run it on—moving forward.

Keith Packard 在 linux.conf.au 峰会上介绍了一个面向教育的项目，他已经在这个项目上从事了大约有一年的时间：这个项目开发了一款针对嵌入式处理器的 Python 版本，名字叫做 “Snek”。正是源于他与一群 10 至 12 岁的学生一起工作的经历导致了他产生发明 Snek 的念头，在会上他还介绍了该语言的一些计划以及运行该语言的硬件。

“Snek” 是一种针对嵌入式处理器的微型可嵌入语言，运行时仅需要几 kB 的 flash 和 ram。这些处理器太小，甚至无法运行 MicroPython（Python 3 语言 的精简高效实现，包括 Python 标准库的一小部分，经过优化可在微控制器和受限环境中运行）。

Snek 借鉴了 python 的语义和语法，但仅提供了该语言的一小部分实现。这么做使得 Snek 程序能够在完整的 Python 环境中运行，同时大家在学习 Snek 时获得的任何知识都可以直接转移到对正式 Python 的学习和使用中。

当前 Snek 1.3 版已发布。该版本增加了对 ESP32 处理器和 μduino 板的支持。有关 “Snek” 的更多介绍可以访问 https://keithp.com/snek/

关键词: Python，Snek

Android display pipeline 的调度问题

Android users make heavy use of the displays on their devices for almost all of their interaction; good display performance is thus critical for a satisfactory user experience. Achieving that performance is not always easy; there are a lot of pieces that need to work together, and the kernel does not always support this collaboration as well as one might like. The Android team is currently considering a number of combinations of existing kernel features and possible enhancements in its efforts to provide the best display experience possible.

Android 用户在交互界面上非常依赖于设备显示；因此，良好的显示性能对于令人满意的用户体验至关重要。实现高效的显示性能并不容易，需要很多部件协同工作，而且内核也不总是像人们所希望的那样对这些协作有较好的支持。 Android 开发团队目前正在考虑对此进行改进，特别是尝试对现有内核功能的多种组合进行尝试，以提供最佳的显示体验。

Android 系统的显示部分由 Android display pipeline 负责管理，Android display pipeline 是一个复杂的系统，在应用程序执行过程中不同的任务和硬件加速器相互协作，确保执行结果通过屏幕呈现给用户。Android display pipeline 负责生成显示输出，因此其性能直接影响用户与设备之间的交互效果。

除了不断增长的移动游戏行业所提出的低延迟要求外，在 display pipeline 中优先考虑的是如何提供稳定的帧速率（不跳过任何帧）。 此外，考虑到 Android 系统在移动设备中所处的领先地位，系统必须满足在有限的能源供给下对散热的严格要求； 这些可以概括为使功耗最小化。 所有这些需求是相互对立的，需要在参与此过程的实体之间进行精确的调整和工作负载分配，并明智地使用 Linux 内核调度程序和 CPU 频率调节器提供的功能，这会直接影响系统的整体性能。

Alessio Balsini 在文章中首先回顾了 Android display pipeline 的工作原理并分析了为何引入复杂的设计的原因 - 提升并发性能。基于以上介绍给出了 Android 开发团队为了改进性能，特别是在内核调度和 CPU 调节上所做的努力和不同的方案介绍。文章写得很赞，对 Android 开发感兴趣的同学可阅读原文 “Scheduling for the Android display pipeline”。

关键词: Android，display pipeline，调度

围绕一个新的系统调用 process_madvise() 的一些讨论

Once upon a time, there were few ways for one process to operate upon another after its creation; sending signals and ptrace() were about it. In recent years, interest in providing ways for processes to control others has been on the increase, and the kernel’s process-management API has been expanded accordingly. Along these lines, the process_madvise() system call has been proposed as a way for one process to influence how memory management is done in another. There is a new process_madvise() series which is interesting in its own right, but this series has also raised a couple of questions about how process management should be improved in general.

曾几何时，一个进程在其创建后只有很少几种办法可以通过另一个进程对其施加影响，譬如发送信号和调用 ptrace()。近年来，人们对在进程中控制其他进程产生了愈来愈多的兴趣。譬如，内核现在提供一个系统调用 madvise() 可以允许一个进程通知内核如何管理其自身的地址空间，但在一些应用场景中（譬如 Android）希望通过一个管理进程去设置其他进程的地址空间管理方式，为此 Minchan Kim 提出了一个新的系统调用 int process_madvise(int pidfd, void *addr, size_t length, int advice, unsigned long flags);。其第一个参数 pidfd 就是用于指定操作的进程对象的，只是这里用的是 pidfd（进程对应的文件描述符），而不是进程号。

这个新的 process_madvise() 函数本身就很有趣，社区在 review 这个补丁的同时围绕这个函数还提出了很多改进进程流程管理的问题。第一个是有关调用这类涉及 pidfd，即访问其他进程的进程的操作权限的问题。正如 Christian Brauner（pidfd 的主要作者）所提出的那样，或许和文件操作的 capabilities 问题类似，针对我们创建的 pidfd，有必要也要为它维护自己的 capabilities。另一个相关的讨论是，有了 pidfd，以后 pid 将何去何从，是否 pid 将完全被 pidfd 完全替代？有的人甚至提出 “All new APIs should use pidfds: they’re better than numeric PIDs in every way”。但显然现在下这样的结论还为时尚早，譬如 Kirill Tkhai 就提出，从实际使用角度出发，pid 应该仍旧保留，也就是说他的想法是新的 API 中应该同时存在 pid 和 pidfd 两个参数，如果是这样，那么上文提到的新的系统调用就应该长成这个样子：int process_madvise(int which, pid_t pid, void *addr, size_t length int advice, unsigned long flag);。其中第一个参数 which 取值为 P_PID 或者 P_PIDFD，用于告诉内核如何解释第二个参数 pid。

看上去社区要好好考虑一下这些有关 pidfd 的问题，毕竟这会涉及到内核系统调用接口的一致性问题，弄得不好，反而会给社区引入混乱。

关键词: Linux, process_madvise()

Linus 亲手优化内核管道代码，大幅提升并发编译性能

For those using GNU Make in particular as their build system, the parallel build times are about to be a lot faster beginning with Linux 5.6 for large core count systems. This landing just after the AMD Threadripper 3990X 64-core / 128-thread CPU launch is one example of systems to benefit from this kernel change when compiling a lot of code and making use of many GNU Make jobs.

Linus Torvalds himself changed around the kernel’s pipe code to use exclusive waits when reading or writing. While this doesn’t mean much for traditional/common piping of data, the GNU Make job-server is a big benefactor as it relies upon a pipe for limiting the parallelism. This technique though employed by the GNU Make job server is inefficient with today’s high core count CPUs as all of the spawned processes are woken up rather than a single reader to be woken upon a writer’s release.

对于那些使用 GNU Make 作为其构建系统的用户，从 Linux 5.6 开始，并行构建速度将快得多。

Linus Torvalds 本人对内核的管道相关代码进行了改进，在读写时使用排他方式的等待处理。这对普通的数据管道操作影响不大，但对于执行 GNU Make 的服务器来说，受益却很大。在 Linus Torvalds 编写的简化测试用例中，此补丁使得测试程序上的上下文切换次数从 1100 万下降到仅 120 万，这无疑会受到欢迎，因为无数的安全漏洞修复使得英特尔设备的上下文切换性能降低了不少。

英特尔的 Josh Triplett 测试了 Linus 的补丁，并确认：“我已经在多个不同的系统上测试了管道修复补丁，在这一个月左右的时间里我没有遇到任何问题。该补丁改善了大型（大约 100 个 CPU）系统上的并行构建时间，包括并行 make 和使用基于管道的其它任务处理工作。”

关键词: Linux，Linus，pipe

联系我们

资讯内容部分来自 “LWN.net“。如果您对某些 LWN 文章感兴趣（譬如希望获得全文翻译的）请扫描二维码加微信联系我们：