[lttng-dev] [RFC PATCH] wfqueue: expand API, simplify implementation, small performance boost

[Mathieu Desnoyers]

* Lai Jiangshan (eag0628 at gmail.com) wrote:
> >>
> >> Is it false sharing?
> >> Access to q->head.next and access to q->tail have the same performance
> >> because they are in the same cache line.
> >
> > Yes! you are right! And a quick benchmark confirms it:
> >
> > with head and tail on same cache line:
> >
> > SUMMARY /home/compudj/doc/userspace-rcu/tests/.libs/lt-test_urcu_wfq testdur   10 nr_enqueuers   1 wdelay      0 nr_dequeuers   1 rdur      0 nr_enqueues    100833595 nr_dequeues     88647134 successful enqueues 100833595 successful dequeues     88646898 end_dequeues 12186697 nr_ops 189480729
> >
> > with a 256 bytes padding between head and tail, keeping the mutex on the
> > "head" cache line:
> >
> > SUMMARY /home/compudj/doc/userspace-rcu/tests/.libs/lt-test_urcu_wfq testdur   10 nr_enqueuers   1 wdelay      0 nr_dequeuers   1 rdur      0 nr_enqueues    228992829 nr_dequeues    228921791 successful enqueues 228992829 successful dequeues    228921367 end_dequeues 71462 nr_ops 457914620
> >
> > enqueue: 127% speedup
> > dequeue: 158% speedup
> >
> > That is indeed a _really_ huge difference. However, to get this, we
> > would have to increase the size of struct cds_wfq_queue beyond its
> > current size, which would break API compatibility. Any idea on how to
> > best do this without causing incompatibility would be welcome.
> >
> 
> choice 1) two set of APIs?(cache-line-opt and none-cache-line-opt),
> many users don't need the cache-line-opt.
> choice 2) Just break the compatibility for NONE-LGPL. I think
> NONE-LGPL-user of it is rare. And current version of urcu <1.0, I
> don't like too much burden when <1.0.

Hi Lai,

Keeping backward compatibility for a while, and gradually deprecating
APIs, is very important for userspace RCU in my opinion: failure to
provide this is the first thing that will discourage users from using
the library. It is also the first thing that will turn away package
maintainers, and distributions, from this project.

I sent 2 patches that implement a compatibility ABI and the new ABI in a
way that will let us continue development on wfqueue without having to
have legacy code in our way: I plan to move all the legacy ABI to
wfqueue0.c, and have a fresh start in terms of ABI for the new wfqueue.
That way, we can eventually remove the wfqueue v0 ABI when we decide to
bump the library version number (and break compatibility).

Feedback is welcome,

Thanks!

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com