ctdb: Adding memory pool for queue callback

[Swen Schillig]

On Wed, 2018-11-07 at 14:32 +0100, Volker Lendecke wrote:
> On Tue, Oct 09, 2018 at 03:01:43PM +1100, Martin Schwenke via samba-
> technical wrote:
> > 
> > Reviewed-by: Martin Schwenke <martin at meltin.net>
> > 
> > Another team reviewer please?
> 
> In theory this looks like a good use of talloc_pool, however I'm not
> sure that this gains us much. Looking at test_speed() in talloc's
> testsuite however surprises me a bit:
> 
> # TALLOC VS MALLOC SPEED
> talloc: 5279300 ops/sec
> talloc_pool: 5498776 ops/sec
> malloc: 8805596 ops/sec
> 
> This is not 100% reproducible with the absolute numbers, but:
> talloc_pool is always a tiny bit faster than talloc, but still
> significantly slower than malloc. Maybe our assumption about
> talloc_pool's speed benefits are just not true anymore. I think it is
> worthwhile to find out where we lose so much performance. I had
> thought that the talloc_pool allocator being just a simple pointer
> increment should be unbeatably fast, but modern malloc seems to be
> even better. A perf run with flamegraphs might reveal more.
> 
> Swen, sorry to send you into another round: You are out for absolute
> lowlevel infrastructure optimizations, and I would like to understand
> first why talloc_pool is so much slower than raw malloc. My hope
> would
> have been that the talloc_pool is much faster than malloc.

Sure, I can investigate.
But whatever the results may be, we would change the way talloc_pool
works and not replace talloc_pool by malloc throwing the talloc API
over bord, right ?

Therefore, I think the suggested change is still valid.

Wouldn't you agree ?

Cheers Swen