摘要： 这几天在做性能的优化, 主要是在kernel的调度模块加了信息采集, 导致延迟增加了100ns, 在经过一系列的优化之后, 延迟较少到了50ns, 不过在检查最后汇编代码的时候 发现有个地方gcc工作得不是很好, 仔细研究了一下. 以下是记录 ``` c代码 void memdelay_enqueue_task(struct task_struct *p, int flags) {
这几天在做性能的优化, 主要是在kernel的调度模块加了信息采集, 导致延迟增加了100ns, 在经过一系列的优化之后, 延迟较少到了50ns, 不过在检查最后汇编代码的时候
发现有个地方gcc工作得不是很好, 仔细研究了一下. 以下是记录
c代码voidmemdelay_enqueue_task(structtask_struct *p,intflags){if(unlikely(!(flags & ENQUEUE_WAKEUP) || p->memdelay_migrate_enqueue)) { memdelay_add_runnable(p); p->memdelay_migrate_enqueue =0; }else{ memdelay_wakeup(p); }}staticinlinevoidmemdelay_wakeup(structtask_struct *task){if(unlikely(task->memdelay_slowpath))return;if(unlikely(task->in_iowait)) memdelay_task_change(task, MTS_IOWAIT, MTS_RUNNABLE);elsememdelay_task_change(task, MTS_NONE, MTS_RUNNABLE);}
函数memdelay_enqueue_task汇编
0xffffffff810d19a0<+0>: callq0xffffffff81930e40<__fentry__>0xffffffff810d19a5<+5>:push%rbp0xffffffff810d19a6<+6>:and$0x1,%esi flags & ENQUEUE_WAKEUP判断0xffffffff810d19a9<+9>:mov%rsp,%rbp 和上面的rbp形成栈帧, 为什么分开, 因为可以乱序0xffffffff810d19ac<+12>:push%rbx0xffffffff810d19ad<+13>:mov%rdi,%rbx 保存p到ebx, 因为ebx是caller保存, 所以要前面push0xffffffff810d19b0<+16>:je0xffffffff810d19d4 flags & ENQUEUE_WAKEUP跳转0xffffffff810d19b2<+18>: movzbl0x8b8(%rdi),%eax 获取p->memdelay_migrate_enqueue0xffffffff810d19b9<+25>:test$0x40,%al 判断p->memdelay_migrate_enqueue0xffffffff810d19bb<+27>:jne0xffffffff810d19d40xffffffff810d19bd<+29>:test%al,%al 判断task->memdelay_slowpath, memdelay_slowpath是最高位, 所以js0xffffffff810d19bf<+31>:js0xffffffff810d19d10xffffffff810d19c1<+33>:test$0x2,%al 判断task->in_iowait0xffffffff810d19c3<+35>:mov$0x2,%edx MTS_RUNNABLE准备参数, 也是因为乱序0xffffffff810d19c8<+40>:jne0xffffffff810d19ef 判断task->in_iowait跳转0xffffffff810d19ca<+42>:xor%esi,%esi 第二个参数,0, memdelay_...(task, MTS_NONE, MTS_RUNNABLE);0xffffffff810d19cc<+44>: callq0xffffffff811f90e00xffffffff810d19d1<+49>:pop%rbx0xffffffff810d19d2<+50>:pop%rbp0xffffffff810d19d3<+51>: retq0xffffffff810d19d4<+52>:mov$0x1,%edx0xffffffff810d19d9<+57>:mov$0x1,%esi0xffffffff810d19de<+62>:mov%rbx,%rdi0xffffffff810d19e1<+65>: callq0xffffffff810d19500xffffffff810d19e6<+70>: andb$0xbf,0x8b8(%rbx)0xffffffff810d19ed<+77>:jmp0xffffffff810d19d10xffffffff810d19ef<+79>:mov$0x1,%esi0xffffffff810d19f4<+84>: callq0xffffffff811f90e00xffffffff810d19f9<+89>:jmp0xffffffff810d19d1
问题
对于上面的汇编, 会想到为什么需要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>: callq0xffffffff81930e40<__fentry__>0xffffffff810d19a5<+5>:push%rbp0xffffffff810d19a6<+6>:and$0x1,%esi0xffffffff810d19a9<+9>:mov%rsp,%rbp0xffffffff810d19ac<+12>:je0xffffffff810d19cf0xffffffff810d19ae<+14>: movzbl0x8b8(%rdi),%eax0xffffffff810d19b5<+21>:test$0x40,%al0xffffffff810d19b7<+23>:jne0xffffffff810d19cf0xffffffff810d19b9<+25>:test%al,%al0xffffffff810d19bb<+27>:js0xffffffff810d19cd0xffffffff810d19bd<+29>:test$0x2,%al0xffffffff810d19bf<+31>:mov$0x2,%edx0xffffffff810d19c4<+36>:jne0xffffffff810d19e70xffffffff810d19c6<+38>:xor%esi,%esi0xffffffff810d19c8<+40>: callq0xffffffff811f90e00xffffffff810d19cd<+45>:pop%rbp0xffffffff810d19ce<+46>: retq0xffffffff810d19cf<+47>: andb$0xbf,0x8b8(%rdi) 直接rdi操作之后0xffffffff810d19d6<+54>:mov$0x1,%edx0xffffffff810d19db<+59>:mov$0x1,%esi0xffffffff810d19e0<+64>: callq0xffffffff810d19500xffffffff810d19e5<+69>:pop%rbp0xffffffff810d19e6<+70>: retq0xffffffff810d19e7<+71>:mov$0x1,%esi0xffffffff810d19ec<+76>: callq0xffffffff811f90e00xffffffff810d19f1<+81>:pop%rbp0xffffffff810d19f2<+82>: retq
函数长度从89减少到82, rbx的操作也没有了, 指令减少3条, 内存操作减少2条
测试下来, 延迟减少10ns
从3.4533915667us到3.4438795333us
如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：yqgroup@service.aliyun.com 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
网友评论