这几天在做性能的优化, 主要是在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 
    
                                                    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 
     
         0xffffffff810d19bd <+29>:    test   %al,%al                                               判断task->memdelay_slowpath, memdelay_slowpath是最高位, 所以js   0xffffffff810d19bf <+31>:    js     0xffffffff810d19d1 
      
          0xffffffff810d19c1 <+33>:    test   $0x2,%al                                               判断task->in_iowait   0xffffffff810d19c3 <+35>:    mov    $0x2,%edx                                               MTS_RUNNABLE准备参数, 也是因为乱序   0xffffffff810d19c8 <+40>:    jne    0xffffffff810d19ef 
       
                                                       判断task->in_iowait跳转   0xffffffff810d19ca <+42>:    xor    %esi,%esi                                               第二个参数, 0, memdelay_...(task, MTS_NONE, MTS_RUNNABLE);   0xffffffff810d19cc <+44>:    callq  0xffffffff811f90e0 
        
            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 
         
           0xffffffff810d19e6 <+70>: andb $0xbf,0x8b8(%rbx) 0xffffffff810d19ed <+77>: jmp 0xffffffff810d19d1 
          
            0xffffffff810d19ef <+79>: mov $0x1,%esi 0xffffffff810d19f4 <+84>: callq 0xffffffff811f90e0 
           
             0xffffffff810d19f9 <+89>: jmp 0xffffffff810d19d1 
            
           
          
         
        
       
      
     
    

问题

对于上面的汇编, 会想到为什么需要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 
    
        0xffffffff810d19ae <+14>:    movzbl 0x8b8(%rdi),%eax   0xffffffff810d19b5 <+21>:    test   $0x40,%al   0xffffffff810d19b7 <+23>:    jne    0xffffffff810d19cf 
     
         0xffffffff810d19b9 <+25>:    test   %al,%al   0xffffffff810d19bb <+27>:    js     0xffffffff810d19cd 
      
          0xffffffff810d19bd <+29>:    test   $0x2,%al   0xffffffff810d19bf <+31>:    mov    $0x2,%edx   0xffffffff810d19c4 <+36>:    jne    0xffffffff810d19e7 
       
           0xffffffff810d19c6 <+38>:    xor    %esi,%esi   0xffffffff810d19c8 <+40>:    callq  0xffffffff811f90e0 
        
            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 
         
           0xffffffff810d19e5 <+69>: pop %rbp 0xffffffff810d19e6 <+70>: retq 0xffffffff810d19e7 <+71>: mov $0x1,%esi 0xffffffff810d19ec <+76>: callq 0xffffffff811f90e0 
          
            0xffffffff810d19f1 <+81>: pop %rbp 0xffffffff810d19f2 <+82>: retq
          
         
        
       
      
     
    

函数长度从89减少到82, rbx的操作也没有了, 指令减少3条, 内存操作减少2条

测试下来, 延迟减少10ns

从3.4533915667us到3.4438795333us