Static Keys 【ChatGPT】

简介: Static Keys 【ChatGPT】

静态键

警告

  • 已弃用的API:
    直接使用'struct static_key'现在已经被弃用。此外,static_key_{true,false}()也已经被弃用。请勿使用以下内容:
struct static_key false = STATIC_KEY_INIT_FALSE;
struct static_key true = STATIC_KEY_INIT_TRUE;
static_key_true()
static_key_false()
  • 更新后的API替代方案如下:
DEFINE_STATIC_KEY_TRUE(key);
DEFINE_STATIC_KEY_FALSE(key);
DEFINE_STATIC_KEY_ARRAY_TRUE(keys, count);
DEFINE_STATIC_KEY_ARRAY_FALSE(keys, count);
static_branch_likely()
static_branch_unlikely()

摘要

静态键允许在性能敏感的快速路径内核代码中包含很少使用的功能,通过GCC特性和代码修补技术实现。以下是一个快速示例:

DEFINE_STATIC_KEY_FALSE(key);
...
if (static_branch_unlikely(&key))
        执行不太可能的代码
else
        执行可能的代码
...
static_branch_enable(&key);
...
static_branch_disable(&key);
...

static_branch_unlikely()分支将以对可能代码路径的最小影响生成到代码中。

动机

目前,跟踪点是使用条件分支实现的。条件检查需要为每个跟踪点检查一个全局变量。尽管此检查的开销很小,但当内存缓存承受压力时(这些全局变量的内存缓存行可能与其他内存访问共享),开销会增加。随着内核中跟踪点数量的增加,这种开销可能变得更加严重。此外,跟踪点通常处于休眠状态(禁用),并且不提供直接的内核功能。因此,尽量减少它们的影响是非常可取的。虽然跟踪点是这项工作的最初动机,但其他内核代码路径应该能够利用静态键功能。

解决方案

gcc(v4.5)添加了一个新的'asm goto'语句,允许跳转到一个标签:

https://gcc.gnu.org/ml/gcc-patches/2009-07/msg01556.html

使用'asm goto',我们可以创建默认情况下被执行或不被执行的分支,而无需检查内存。然后,在运行时,我们可以修补分支位置以改变分支方向。

例如,如果我们有一个默认情况下被禁用的简单分支:

if (static_branch_unlikely(&key))
        printk("I am the true branch\n");

因此,默认情况下不会发出'printk'。生成的代码将由一个单独的原子'no-op'指令(在x86上为5个字节)组成,位于直线代码路径中。当分支被'翻转'时,我们将在直线代码路径中的'no-op'修补为一个'jump'指令,以跳转到离线的真分支。因此,改变分支方向是昂贵的,但分支选择基本上是'免费'的。这是这种优化的基本权衡。

这种低级修补机制称为'跳转标签修补',它为静态键功能提供了基础。

静态键标签API、用法和示例

为了利用这种优化,您首先必须定义一个键:

DEFINE_STATIC_KEY_TRUE(key);

或者:

DEFINE_STATIC_KEY_FALSE(key);

键必须是全局的,即不能在堆栈上分配或在运行时动态分配。

然后,在代码中使用该键:

if (static_branch_unlikely(&key))
        执行不太可能的代码
else
        执行可能的代码

或者:

if (static_branch_likely(&key))
        执行可能的代码
else
        执行不太可能的代码

通过DEFINE_STATIC_KEY_TRUE()或DEFINE_STATIC_KEY_FALSE定义的键可以在static_branch_likely()或static_branch_unlikely()语句中使用。

可以通过以下方式将分支设置为true:

static_branch_enable(&key);

或通过以下方式将分支设置为false:

static_branch_disable(&key);

然后,可以通过引用计数切换分支:

static_branch_inc(&key);
...
static_branch_dec(&key);

因此,'static_branch_inc()'表示'使分支为true','static_branch_dec()'表示'使分支为false',并进行适当的引用计数。例如,如果键初始化为true,则static_branch_dec()将将分支切换为false。然后,随后的static_branch_inc()将分支改回true。同样,如果键初始化为false,则'static_branch_inc()'将分支改为true。然后,'static_branch_dec()'将再次使分支为false。

可以使用'static_key_enabled()'和'static_key_count()'获取状态和引用计数。通常情况下,如果使用这些函数,应该使用与启用/禁用或增加/减少函数相同的互斥锁进行保护。

请注意,切换分支会导致一些锁被获取,特别是CPU热插拔锁(为了避免内核在修补期间引入CPU时发生竞争)。因此,在热插拔通知器中调用静态键API肯定会导致死锁。为了仍然允许使用该功能,提供了以下函数:

static_key_enable_cpuslocked() static_key_disable_cpuslocked() static_branch_enable_cpuslocked() static_branch_disable_cpuslocked()

这些函数不是通用的,只能在确切知道自己处于上述上下文且没有其他上下文时使用。

如果需要一个键的数组,可以定义为:

DEFINE_STATIC_KEY_ARRAY_TRUE(keys, count);

或者:

DEFINE_STATIC_KEY_ARRAY_FALSE(keys, count);

架构级代码修补接口,'跳转标签'

为了利用这种优化,架构必须实现一些函数和宏。如果没有架构支持,我们将简单地回退到传统的加载、测试和跳转序列。此外,struct jump_entry表的对齐方式必须至少为4字节,因为static_key->entry字段使用了最低的两个有效位。

  • 选择HAVE_ARCH_JUMP_LABEL,
参见:arch/x86/Kconfig
  • define JUMP_LABEL_NOP_SIZE,
参见:arch/x86/include/asm/jump_label.h
  • __always_inline bool arch_static_branch(struct static_key *key, bool branch),
参见:arch/x86/include/asm/jump_label.h
  • __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch),
参见:arch/x86/include/asm/jump_label.h
  • void arch_jump_label_transform(struct jump_entry *entry, enum jump_label_type type),
参见:arch/x86/kernel/jump_label.c
  • struct jump_entry,
参见:arch/x86/include/asm/jump_label.h

静态密钥/跳转标签分析结果(x86_64):

举个例子,让我们给'getppid()'添加以下分支,使得系统调用看起来像这样:

SYSCALL_DEFINE0(getppid)
{
      int pid;
+     if (static_branch_unlikely(&key))
+             printk("我是真分支\n");
      rcu_read_lock();
      pid = task_tgid_vnr(rcu_dereference(current->real_parent));
      rcu_read_unlock();
      return pid;
}

GCC生成的带有跳转标签的结果指令是:

ffffffff81044290 <sys_getppid>:
ffffffff81044290:       55                      push   %rbp
ffffffff81044291:       48 89 e5                mov    %rsp,%rbp
ffffffff81044294:       e9 00 00 00 00          jmpq   ffffffff81044299 <sys_getppid+0x9>
ffffffff81044299:       65 48 8b 04 25 c0 b6    mov    %gs:0xb6c0,%rax
ffffffff810442a0:       00 00
ffffffff810442a2:       48 8b 80 80 02 00 00    mov    0x280(%rax),%rax
ffffffff810442a9:       48 8b 80 b0 02 00 00    mov    0x2b0(%rax),%rax
ffffffff810442b0:       48 8b b8 e8 02 00 00    mov    0x2e8(%rax),%rdi
ffffffff810442b7:       e8 f4 d9 00 00          callq  ffffffff81051cb0 <pid_vnr>
ffffffff810442bc:       5d                      pop    %rbp
ffffffff810442bd:       48 98                   cltq
ffffffff810442bf:       c3                      retq
ffffffff810442c0:       48 c7 c7 e3 54 98 81    mov    $0xffffffff819854e3,%rdi
ffffffff810442c7:       31 c0                   xor    %eax,%eax
ffffffff810442c9:       e8 71 13 6d 00          callq  ffffffff8171563f <printk>
ffffffff810442ce:       eb c9                   jmp    ffffffff81044299 <sys_getppid+0x9>

没有跳转标签优化的情况下,看起来像:

ffffffff810441f0 <sys_getppid>:
ffffffff810441f0:       8b 05 8a 52 d8 00       mov    0xd8528a(%rip),%eax        # ffffffff81dc9480 <key>
ffffffff810441f6:       55                      push   %rbp
ffffffff810441f7:       48 89 e5                mov    %rsp,%rbp
ffffffff810441fa:       85 c0                   test   %eax,%eax
ffffffff810441fc:       75 27                   jne    ffffffff81044225 <sys_getppid+0x35>
ffffffff810441fe:       65 48 8b 04 25 c0 b6    mov    %gs:0xb6c0,%rax
ffffffff81044205:       00 00
ffffffff81044207:       48 8b 80 80 02 00 00    mov    0x280(%rax),%rax
ffffffff8104420e:       48 8b 80 b0 02 00 00    mov    0x2b0(%rax),%rax
ffffffff81044215:       48 8b b8 e8 02 00 00    mov    0x2e8(%rax),%rdi
ffffffff8104421c:       e8 2f da 00 00          callq  ffffffff81051c50 <pid_vnr>
ffffffff81044221:       5d                      pop    %rbp
ffffffff81044222:       48 98                   cltq
ffffffff81044224:       c3                      retq
ffffffff81044225:       48 c7 c7 13 53 98 81    mov    $0xffffffff81985313,%rdi
ffffffff8104422c:       31 c0                   xor    %eax,%eax
ffffffff8104422e:       e8 60 0f 6d 00          callq  ffffffff81715193 <printk>
ffffffff81044233:       eb c9                   jmp    ffffffff810441fe <sys_getppid+0xe>
ffffffff81044235:       66 66 2e 0f 1f 84 00    data32 nopw %cs:0x0(%rax,%rax,1)
ffffffff8104423c:       00 00 00 00

因此,禁用跳转标签的情况下,相比于使用跳转标签的情况,会增加一个'mov'、'test'和'jne'指令,而使用跳转标签的情况下只有一个'no-op'或'jmp 0'指令。('jmp 0'在启动时被修补为一个5字节的原子no-op指令。)因此,禁用跳转标签的情况下增加了:

6(mov)+ 2(test)+ 2(jne)= 10 - 5(5字节跳转0)= 5个额外字节。

如果我们考虑填充字节,跳转标签代码节省了16个指令内存字节。在这种情况下,不使用跳转标签的函数长度为80字节。因此,我们节省了20%的指令占用空间。实际上,我们甚至可以进一步改进,因为5字节的no-op实际上可以是2字节的no-op,因为我们可以用2字节的jmp到达分支。然而,我们还没有实现最佳的no-op大小(它们目前是硬编码的)。

由于调度程序路径中存在许多静态密钥API用法,可以使用'pipe-test'(也称为'perf bench sched pipe')来显示性能改进。在3.3.0-rc2上进行的测试如下:

禁用跳转标签:

执行'bash -c /tmp/pipe-test'的性能计数器统计(50次运行):

Performance counter stats for 'bash -c /tmp/pipe-test' (50 runs):
855.700314 task-clock                #    0.534 CPUs utilized            ( +-  0.11% )
200,003 context-switches          #    0.234 M/sec                    ( +-  0.00% )
0 CPU-migrations            #    0.000 M/sec                    ( +- 39.58% )
487 page-faults               #    0.001 M/sec                    ( +-  0.02% )
1,474,374,262 cycles                    #    1.723 GHz                      ( +-  0.17% )
  <not supported> stalled-cycles-frontend
  <not supported> stalled-cycles-backend
1,178,049,567 instructions              #    0.80  insns per cycle          ( +-  0.06% )
208,368,926 branches                  #  243.507 M/sec                    ( +-  0.06% )
5,569,188 branch-misses             #    2.67% of all branches          ( +-  0.54% )
1.601607384 seconds time elapsed                                          ( +-  0.07% )

启用跳转标签:

执行'bash -c /tmp/pipe-test'的性能计数器统计(50次运行):

Performance counter stats for 'bash -c /tmp/pipe-test' (50 runs):
841.043185 task-clock                #    0.533 CPUs utilized            ( +-  0.12% )
200,004 context-switches          #    0.238 M/sec                    ( +-  0.00% )
0 CPU-migrations            #    0.000 M/sec                    ( +- 40.87% )
487 page-faults               #    0.001 M/sec                    ( +-  0.05% )
1,432,559,428 cycles                    #    1.703 GHz                      ( +-  0.18% )
  <not supported> stalled-cycles-frontend
  <not supported> stalled-cycles-backend
1,175,363,994 instructions              #    0.82  insns per cycle          ( +-  0.04% )
206,859,359 branches                  #  245.956 M/sec                    ( +-  0.04% )
4,884,119 branch-misses             #    2.36% of all branches          ( +-  0.85% )
1.579384366 seconds time elapsed

节省的分支百分比为0.7%,我们在'branch-misses'上节省了12%。这正是我们期望获得最大节省的地方,因为这种优化是为了减少分支的数量。此外,我们在指令上节省了0.2%,在周期上节省了2.8%,在经过时间上节省了1.4%。

相关文章
|
安全 虚拟化
GIC规格学习(一)
GIC规格学习(一)
523 0
|
存储 NoSQL 数据库
时序数据库连载系列: 时序数据库一哥InfluxDB之存储机制解析
InfluxDB 的存储机制解析 本文介绍了InfluxDB对于时序数据的存储/索引的设计。由于InfluxDB的集群版已在0.12版就不再开源,因此如无特殊说明,本文的介绍对象都是指 InfluxDB 单机版 1. InfluxDB 的存储引擎演进 尽管InfluxDB自发布以来历时三年多,其存储引擎的技术架构已经做过几次重大的改动, 以下将简要介绍一下InfluxDB的存储引擎演进的过程。
7112 0
|
Android开发
Android5.0 Recovery源代码分析与定制(一)
Android5.0 Recovery源代码分析与定制(一)
307 0
|
安全 数据安全/隐私保护 Android开发
AVB源码学习(二):Uboot阶段AVB2.0校验流程
AVB源码学习(二):Uboot阶段AVB2.0校验流程
772 0
|
7月前
|
大数据
“你朋友圈的真面目,大数据都知道!”——用社交网络分析看透人情世故
“你朋友圈的真面目,大数据都知道!”——用社交网络分析看透人情世故
250 16
|
Java Android开发 iOS开发
深入探讨移动操作系统的性能优化:安卓与iOS的对比分析
在现代移动设备中,操作系统的性能优化至关重要。本文从系统架构、内存管理、电池续航和应用程序运行效率等多个维度,深入探讨了安卓(Android)和iOS两大主流移动操作系统的优化策略及其实际效果,旨在为开发者和用户提供更清晰的了解和选择依据。
1346 27
|
存储 人工智能 安全
阿里云服务器通用型g7、g8a、g8y、g8i实例区别及选择指南
目前在阿里云的活动中,属于通用型实例规格的云服务器有通用型g7、通用型g8a、通用型g8y和通用型g8i这几个实例规格,相比于活动内的经济型e和通用算力型u1等实例规格来说,这些实例规格等性能更强,虽然这几个实例规格的云服务器通常处理器与内存的配比为都是1:4,但是他们在处理器、存储、网络、安全等方面等性能并不是一样的,所以他们的适用场景也有着不同。本文为大家介绍通用型g7、g8a、g8y、g8i实例的性能、适用场景的区别以及选择参考。
|
Android开发
Android 中ProgressDialog进度条对话框的使用(使用子线程模拟更新进度)
Android 中ProgressDialog进度条对话框的使用(使用子线程模拟更新进度)
449 0
|
负载均衡 网络协议 Linux
Linux内核 RPS/RFS功能详细测试分析
Linux内核 RPS/RFS功能详细测试分析
1436 0
|
缓存 程序员 Linux
ARM中断来瞅瞅
ARM中断来瞅瞅
319 0