[systemd-devel] kdbus performance regression by ~70% on 3.15 kernels ?

[Daniel Mack]

On 06/28/2014 01:55 AM, Steven Noonan wrote:
> Was going to try to repro this perf regression as well, but instead got
> kdbus to oops (via test-kdbus-benchmark):
> 
> $ test/test-kdbus-benchmark 
> -- opening /dev/kdbus/control
> -- creating bus '1000-testbus'
> -- opening bus connection /dev/kdbus/1000-testbus/bus
> -- Our peer ID for /dev/kdbus/1000-testbus/bus: 1 -- bus uuid:
> 'b65bfdd23d3e4696aae2992a0857aa33'
> -- opening bus connection /dev/kdbus/1000-testbus/bus
> -- Our peer ID for /dev/kdbus/1000-testbus/bus: 2 -- bus uuid:
> 'b65bfdd23d3e4696aae2992a0857aa33'
> name_acquire(): flags after call: 0x0                                                                                                
> Killed
> $

...


> [   33.558642] Stack:
> [   33.558650]  ffffffffa11f45d6 0000000000000000 ffff8800c82cff50 0000000000000010
> [   33.558681]  00007fff80d23800 ffff8800c82cff50 0000000000000000 ffff8800c82cfef8
> [   33.558712]  ffffffff811d386a 00007fff80d23800 0000000000000010 ffff8803f9d5d400
> [   33.558743] Call Trace:
> [   33.558757]  [<ffffffffa11f45d6>] ? kdbus_memfd_writev+0x66/0xa0 [kdbus]

This bug is fixed upstream with 7da2745e ("memfd: switch to
f_op->{read,write}_iter"). This fix was neccessary due to vfs internal
refactoring that came in for 3.16-rc1.

Bisecting between v3.15 and 3.16-rc1 can hence be a little tricky. You
might have to revert this particular patch for some bisect iterations in
case you get build breakage.

It might also be a good idea to investigate whether one specific meta
data attachments causes the regression.


Thanks,
Daniel