泰晓科技 -- 聚焦 Linux - 追本溯源,见微知著!
网站地址:http://tinylab.org
请稍侯

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

Wang Chen 创作于 2020/02/05

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

  • Linux Lab 发布 v0.3 rc2,大幅提升使用体验

    Linux Lab 是一套用于 Linux 内核学习、开发和测试的即时实验室,可以极速搭建和使用,功能强大,用法简单!

    本次发布 v0.3 的第 2 个候选版本:v0.3 rc2,随同发布的还有 Cloud Lab v0.1 的第 1 个正式版本:v0.1

    Linux Lab v0.3 rc1 新增了对多本经典 Linux 图书所采用的 Linux 内核提供支持,而 v0.3 rc2 则大幅提升了使用体验。

    下面是一些重要变更:

    • 修复多处 Windows 兼容问题
    • 提升 git 仓库下载体验:所有仓库下载切换为 git init+fetch,更为健壮
      • 新增基于 git init+fetch 的 clone 脚本:tools/git/clone.sh
    • 提升自动化:常规动作都新增了依赖关系,一键自动下载、检出、打补丁、配置、编译、启动
    • 允许自定义本地配置,可同时进行升级,下述配置文件仅限本地可用
      • boards/<BOARD>/Makefile.{init,beforeconfig,config,afterconfig,fini}.private
    • 大幅共享和删减代码,核心代码仅 2607 行

    关键词: Linux Lab, v0.3-rc2

  • 与性能相关的 BPF 修补程序

    One of the advantages of the in-kernel BPF virtual machine is that it is fast. BPF programs are just-in-time compiled and run directly by the CPU, so there is no interpreter overhead. For many of the intended use cases, though, “fast” can never be quite fast enough. It is thus unsurprising that there are currently a number of patch sets under development that are intended to speed up one aspect or another of using BPF in the system. A few, in particular, seem about ready to hit the mainline.

    Linux 内核中支持 BPF 虚拟机带来的众多好处之一就是运行速度快。BPF 程序采用 JIT(just-in-time)方式编译后再在机器上运行,不通过解释器的好处就是带来了高效的运行速度。不过在很多场景下,这还不够快。为此,近来有很多补丁致力于从不同方面加速 BPF 的执行速度。其中有一些已经足够成熟,可以被合入到内核主线了。这里给大家介绍几个比较突出的补丁例子,更多内容请阅读原文 “A medley of performance-related BPF patches”

    • 第一个是 Bjorn Topel 提交的 BPF dispatcher patch set。提出该补丁的背景如下:我们知道 BPF 程序需要通过 attach 到一个特定调用点之后才可以被执行。例如用于调试跟踪的程序会被 attach 到 tracepoint 的位置,而网络 XDP (express data path) 程序则会被 attach 到某个特定的网络设备。通常来说,在任何一个 attach 点都可以 attach 多个 BPF 程序。在需要运行的时候,内核会遍历一个链表结构依次运行这些 BPF 程序。实际执行某个 BPF 程序时是通过一个间接跳转(indirect jump)指令来实现。这么做本来就不算快,后来在处理 speculative-execution 漏洞时,又把该机制改成了 retpoline 方式,但也进一步拖慢了执行的速度。特别是对那些需要频繁调用 BPF 函数的场景,例如 XDP 需要对每个网络包进行处理,那么每次执行所拖慢的一点速度,累积起来就会产生较大影响。Bjorn Topel 的补丁致力于修改 retpoline 方式,根据补丁测试的报告来看,目前的新做法比 retpoline 快了大概三分之一左右。这组补丁目前已经是第五版,有希望很快被合入主线。

    • 第二个是有关用户态应用访问 BPF 程序维护的数据,目前的做法是通过 bpf() 系统调用。如果用户只是想在执行的最后一次性读出运算结果,那么调用一次bpf() 不算什么问题。可是有时候用户态程序需要长时间运行并持续访问 BPF 里面的大量数据的话,频繁调用这个函数累积出来的开销就不能忽视了。Andrii Nakryiko 采用 memory-mappable BPF maps 补丁部分地解决了这个问题。他采取进程地址映射的方法使得用户态进程可以直接访问 BPF 内部的数据,避免了频繁的系统调用。这个补丁已经合入 BPF 代码仓库了,预计会合入 5.6 内核版本。

    • 和第二个改进的出发点相同,都是为了减少 bpf() 系统调用的次数。Brian Vazquez 提出了另一个方法,batched operations patch set。该方法还是需要通过系统调用,但一次系统调用就能操作 100个(甚至更多的)元素,不像以前只能操作 1 个元素。同样达到了大大减少系统调用数量的目的。这组补丁已经进化到第三版,看起来也会在近期合入主线。

    关键词: Linux,BPF

  • IPv6 的扩展头部字段引起的问题!

    It has taken longer than anybody might have liked, but the IPv6 protocol is slowly displacing IPv4 across the Internet. A quick, highly scientific “grep the access logs” test shows that about 16% of the traffic to LWN.net is currently using IPv6, and many large corporate networks are using IPv6 exclusively internally. This version of the IP protocol was designed to be more flexible than IPv4 in a number of ways; the “extension header” mechanism is one way in which that flexibility is achieved. A proposal to formalize extension-header processing in the kernel’s networking stack has led to some concerns, though, about how this feature will be used and what role Linux should play in its development.

    尽管花费的时间比大多数人预料的都要长,不过 IPv6 确实正在互联网上慢慢地替代 IPv4。IPv6 协议在设计时,很多方面的自由度都比 IPv4 要更大,其中一个利于扩展性的功能就是 “extension header” 机制。IPv4 的头部信息都是明确规定好的,很难在其中增加新的信息。IPv6 增加了一个 extension header 字段,可以用来方便在将来能更容易地添加新的信息。Tom Herbert 一直着力于开发一系列补丁来规范 Linux 中修改 IPv6 extension header 的处理方式。譬如他希望提供一个框架,允许使用内核模块的方式来注册特定的扩展选项。

    可是网络子系统的维护者 David Miller 不太喜欢这个功能,他认为这个功能很容易被政府等机构滥用,也可能被互联网服务提供商用来导致产生一些损害用户意愿和公平性的行为,譬如用于数据监控和权限限制的场景。Herbert 也承认 Miller 的担心有道理,不过他认为无论 Linux 是否支持这个功能,路由器设备厂商都会找到自己的办法来实现以上功能。上述这些不合理的用法,甚至都并不需要用到 extension header。而如果我们在内核里面规范了 extension header 的使用的话,其实可能反而会减少今后的这些滥用行为。因为 Linux 对网络生态是极其重要的,也是唯一一个会对协议具体实现方式进行仔细审查的开发平台。如果 Linux 不做这件事,其他替代系统反而会有可能被大力推广从而占据了领先地位,结果 Linxx 社区反而会显得更被动,并且无法保证替代系统不推出滥用协议的标准和规范。

    总而言之我们是应该拒绝这个功能,还是试图接受它然后通过有效的改造来避免滥用,这是内核网络社区接下来需要面对的一个问题。更多内容请阅读原文 “The trouble with IPv6 extension headers”

    关键词: Linux,IPv6,

联系我们

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

tinylab wechat



Read Album:

Read Related:

Read Latest: