Comment 2 for bug 1876230

Hi @mruffell,

two questions for this sru:

1) it looks like static libs are built/provided by this package:

$ pull-lp-debs liburcu bionic ; for p in *.deb ; do echo "$p:" ; dpkg-deb -c $p | grep -E '*\.a' ; done
Found liburcu 0.10.1-1 in bionic
Using existing file liburcu-dev_0.10.1-1_amd64.deb
Using existing file liburcu6_0.10.1-1_amd64.deb
liburcu6_0.10.1-1_amd64.deb:
liburcu-dev_0.10.1-1_amd64.deb:
-rw-r--r-- root/root 47956 2018-01-23 15:46 ./usr/lib/x86_64-linux-gnu/liburcu-bp.a
-rw-r--r-- root/root 69844 2018-01-23 15:46 ./usr/lib/x86_64-linux-gnu/liburcu-cds.a
-rw-r--r-- root/root 23912 2018-01-23 15:46 ./usr/lib/x86_64-linux-gnu/liburcu-common.a
-rw-r--r-- root/root 43750 2018-01-23 15:46 ./usr/lib/x86_64-linux-gnu/liburcu-mb.a
-rw-r--r-- root/root 45642 2018-01-23 15:46 ./usr/lib/x86_64-linux-gnu/liburcu-qsbr.a
-rw-r--r-- root/root 45716 2018-01-23 15:46 ./usr/lib/x86_64-linux-gnu/liburcu-signal.a
-rw-r--r-- root/root 45148 2018-01-23 15:46 ./usr/lib/x86_64-linux-gnu/liburcu.a

and several other pkgs have build-dep for that:

$ reverse-depends -b -r bionic liburcu-dev
Reverse-Build-Depends
* gdnsd
* glusterfs
* knot
* ltt-control
* multipath-tools
* netsniff-ng
* sheepdog
* ust

Can you check those packages to see if any use static linking (and thus should be recompiled with the updated static liburcu libs)?

2) In your testing results comparison:

> ./test_urcu 6 2 10
> 0.10.1-1: 17612527667 reads, 268 writes, 17612527935 ops
> 0.10.1-1ubuntu1: 14988437247 reads, 810069 writes, 14989247316 ops

The number of writes is obviously much, much better; however the number of reads actually goes down with the patched code.

> $ ./test_urcu_bp 6 2 10
> 0.10.1-1: 1177891079 reads, 1699523 writes, 1179590602 ops
> 0.10.1-1ubuntu1: 13230354737 reads, 575314 writes, 13230930051 ops

Similarly, while the number of reads increases significantly, the number of writes goes down.

I may be misreading the results, but it seems like this change is not an across-the-board improvement, but more of a performance trade-off. If that's the case, I think it will be hard to make the case this should be included as an SRU. Can you clarify the results comparison in more detail please?