这几天在做性能的优化, 主要是在kernel的调度模块加了信息采集, 导致延迟增加了100ns, 在经过一系列的优化之后, 延迟较少到了50ns, 不过在检查最后汇编代码的时候
发现有个地方gcc工作得不是很好, 仔细研究了一下. 以下是记录

c代码
void memdelay_enqueue_task(struct task_struct *p, int flags)
{
    if (unlikely(!(flags & ENQUEUE_WAKEUP) || p->memdelay_migrate_enqueue)) {
        memdelay_add_runnable(p);
        p->memdelay_migrate_enqueue = 0;
    } else {
        memdelay_wakeup(p);
    }
}
static inline void memdelay_wakeup(struct task_struct *task)
{
    if (unlikely(task->memdelay_slowpath))
        return;

    if (unlikely(task->in_iowait))
        memdelay_task_change(task, MTS_IOWAIT, MTS_RUNNABLE);
    else
        memdelay_task_change(task, MTS_NONE, MTS_RUNNABLE);
}

函数memdelay_enqueue_task汇编

   0xffffffff810d19a0 <+0>:     callq  0xffffffff81930e40 <__fentry__>
   0xffffffff810d19a5 <+5>:     push   %rbp

   0xffffffff810d19a6 <+6>:     and    $0x1,%esi
                                              flags & ENQUEUE_WAKEUP判断

   0xffffffff810d19a9 <+9>:     mov    %rsp,%rbp
                                              和上面的rbp形成栈帧, 为什么分开, 因为可以乱序

   0xffffffff810d19ac <+12>:    push   %rbx
   0xffffffff810d19ad <+13>:    mov    %rdi,%rbx
                                               保存p到ebx, 因为ebx是caller保存, 所以要前面push

   0xffffffff810d19b0 <+16>:    je     0xffffffff810d19d4 <memdelay_enqueue_task+52>
                                               flags & ENQUEUE_WAKEUP跳转

   0xffffffff810d19b2 <+18>:    movzbl 0x8b8(%rdi),%eax
                                               获取p->memdelay_migrate_enqueue

   0xffffffff810d19b9 <+25>:    test   $0x40,%al
                                               判断p->memdelay_migrate_enqueue
   0xffffffff810d19bb <+27>:    jne    0xffffffff810d19d4 <memdelay_enqueue_task+52>

   0xffffffff810d19bd <+29>:    test   %al,%al
                                               判断task->memdelay_slowpath, memdelay_slowpath是最高位, 所以js
   0xffffffff810d19bf <+31>:    js     0xffffffff810d19d1 <memdelay_enqueue_task+49>

   0xffffffff810d19c1 <+33>:    test   $0x2,%al
                                               判断task->in_iowait

   0xffffffff810d19c3 <+35>:    mov    $0x2,%edx
                                               MTS_RUNNABLE准备参数, 也是因为乱序

   0xffffffff810d19c8 <+40>:    jne    0xffffffff810d19ef <memdelay_enqueue_task+79>
                                               判断task->in_iowait跳转
   0xffffffff810d19ca <+42>:    xor    %esi,%esi
                                               第二个参数, 0, memdelay_...(task, MTS_NONE, MTS_RUNNABLE);
   0xffffffff810d19cc <+44>:    callq  0xffffffff811f90e0 <memdelay_task_change>
   0xffffffff810d19d1 <+49>:    pop    %rbx
   0xffffffff810d19d2 <+50>:    pop    %rbp
   0xffffffff810d19d3 <+51>:    retq
   0xffffffff810d19d4 <+52>:    mov    $0x1,%edx
   0xffffffff810d19d9 <+57>:    mov    $0x1,%esi
   0xffffffff810d19de <+62>:    mov    %rbx,%rdi
   0xffffffff810d19e1 <+65>:    callq  0xffffffff810d1950 <memdelay_del_add>
   0xffffffff810d19e6 <+70>:    andb   $0xbf,0x8b8(%rbx)
   0xffffffff810d19ed <+77>:    jmp    0xffffffff810d19d1 <memdelay_enqueue_task+49>
   0xffffffff810d19ef <+79>:    mov    $0x1,%esi
   0xffffffff810d19f4 <+84>:    callq  0xffffffff811f90e0 <memdelay_task_change>
   0xffffffff810d19f9 <+89>:    jmp    0xffffffff810d19d1 <memdelay_enqueue_task+49>

问题

对于上面的汇编, 会想到为什么需要push rbx, mov %rdi,%rbx来保存p指针, 因为rbx是callee保存, 因为这样会导致一次push, 一次pop, 2次内存访问, 用rcx不就好了, 不用push, pop了. r8 r9都可以用啊.

答案

经过一系列的实验, 研究之后终于发现gcc为什么这么做

memdelay_add_runnable(p);
p->memdelay_migrate_enqueue = 0;

原因

在调用函数memdelay_add_runnable之后, 还需要用到变量p, 调用memdelay_add_runnable的时候p保存在rdi里面, 调用memdelay_add_runnable之后, rdi的值就得不到保证了, 所以需要找个地方另存p, 也就是rdi

另一个问题, 为什么要选择需要push, pop的rbx, 而不是简单rcx(rcx可以随便用)
解释起来也很简单, 如果选择rcx, 经过memdelay_add_runnable调用之后, 他的值也得不到保证, 所以只能选择callee保存的寄存器, 这样才不会被memdelay_add_runnable破坏, 既然这样, 那么memdelay_enqueue_task也不能破解callee保存的寄存器(比如rbx), 所以一定会导致push和pop

找到原因之后就简单了, 把p->memdelay_migrate_enqueue = 0;提到调用memdelay_add_runnable的前面去(当然逻辑是可以提的), 这样p->memdelay_migrate_enqueue = 0这条语句就可以直接使用rdi来操作了

更改之后的汇编
   0xffffffff810d19a0 <+0>:     callq  0xffffffff81930e40 <__fentry__>
   0xffffffff810d19a5 <+5>:     push   %rbp
   0xffffffff810d19a6 <+6>:     and    $0x1,%esi
   0xffffffff810d19a9 <+9>:     mov    %rsp,%rbp
   0xffffffff810d19ac <+12>:    je     0xffffffff810d19cf <memdelay_enqueue_task+47>
   0xffffffff810d19ae <+14>:    movzbl 0x8b8(%rdi),%eax
   0xffffffff810d19b5 <+21>:    test   $0x40,%al
   0xffffffff810d19b7 <+23>:    jne    0xffffffff810d19cf <memdelay_enqueue_task+47>
   0xffffffff810d19b9 <+25>:    test   %al,%al
   0xffffffff810d19bb <+27>:    js     0xffffffff810d19cd <memdelay_enqueue_task+45>
   0xffffffff810d19bd <+29>:    test   $0x2,%al
   0xffffffff810d19bf <+31>:    mov    $0x2,%edx
   0xffffffff810d19c4 <+36>:    jne    0xffffffff810d19e7 <memdelay_enqueue_task+71>
   0xffffffff810d19c6 <+38>:    xor    %esi,%esi
   0xffffffff810d19c8 <+40>:    callq  0xffffffff811f90e0 <memdelay_task_change>
   0xffffffff810d19cd <+45>:    pop    %rbp
   0xffffffff810d19ce <+46>:    retq
   0xffffffff810d19cf <+47>:    andb   $0xbf,0x8b8(%rdi) 直接rdi操作之后
   0xffffffff810d19d6 <+54>:    mov    $0x1,%edx
   0xffffffff810d19db <+59>:    mov    $0x1,%esi
   0xffffffff810d19e0 <+64>:    callq  0xffffffff810d1950 <memdelay_del_add>
   0xffffffff810d19e5 <+69>:    pop    %rbp
   0xffffffff810d19e6 <+70>:    retq
   0xffffffff810d19e7 <+71>:    mov    $0x1,%esi
   0xffffffff810d19ec <+76>:    callq  0xffffffff811f90e0 <memdelay_task_change>
   0xffffffff810d19f1 <+81>:    pop    %rbp
   0xffffffff810d19f2 <+82>:    retq

函数长度从89减少到82, rbx的操作也没有了, 指令减少3条, 内存操作减少2条
测试下来, 延迟减少10ns

从3.4533915667us到3.4438795333us