ctdb: Adding memory pool for queue callback

Volker Lendecke Volker.Lendecke at SerNet.DE
Wed Nov 7 15:07:51 UTC 2018


On Wed, Nov 07, 2018 at 04:01:02PM +0100, Swen Schillig wrote:
> In the area where the pool is introduced we almost always have the
> situation that no memory from the pool is used (all mem available)
> and we just want to make use of the fact that we re-use this memory.

Right, and this is what the talloc speedtest under
lib/talloc/testsuite.c:855ff also attempts.

> I just wrote a quick program which is simulating this scenrario with
> the 3 different options with which we could get such memory with the
> following result
> 
> [swen at linux ~]$ ./a.out
> It took 2.219697 seconds to execute 10 million talloc/free cycles.
> It took 1.450206 seconds to execute 10 million talloc(pool)/free cycles.

There must be a significant difference to the test program in
lib/talloc/testsuite.c and yours. Why is your difference closer to a
factor of 2 and not 2% like in lib/talloc/testsuite.c, and does that
precisely match 

> It took 1.068344 seconds to execute 10 million malloc/free cycles.
> 
> ...and yes we will not see those differences in reality, however we did
> see enough improvement to make this small change.
> 
> So I'm afraid I don't fully understand your argument against this
> patch. Do you question the talloc_pool "feature" in total or just the
> way it was used by me in this patch ?

In the talloc testsuite the micro-benchmark does not gain a factor of
2 but just 2%. For those 2% gain in a tiny fraction of the whole ctdb
packet processing I would not agree to add any complexity. If you can
explain the difference between your measured factor 2 and the 2% from
the testsuite, it might be different.

With best regards,

Volker Lendecke

-- 
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