ctdb: Adding memory pool for queue callback

Volker Lendecke Volker.Lendecke at SerNet.DE
Wed Nov 7 13:32:23 UTC 2018


On Tue, Oct 09, 2018 at 03:01:43PM +1100, Martin Schwenke via samba-technical wrote:
> I'd prefer to see the commit message mention that the pool doesn't
> cover all cases due to some cases being handled asynchronously.
> 
> However, the patch itself will provide a significant reduction in the
> number of malloc()s, so:
> 
> 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.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de



More information about the samba-technical mailing list