Re: [Tarantool-patches] [PATCH] small: unite the oscillation cache of all mempools

[Aleksandr Lyapunov <alyapunov@tarantool.org>]

Yes, there is a case when we waste lots of memory. But I think that
the case case of split/merge hammering is not so impossible. I guess
there some workloads when tuple lifetime is very shot, perhaps queue.
If we add to the workload use of tuples of different sizes, from dozens
of small slabs, we'll get a case where small mempools very frequently
switch between empty and non-empty states. And if the average number
of non-empty small mempools is around some magic numbers (power
of two if all slabs have the same size) then there could some significant
performance difference.
This case is not frequent though, but we should not degrade worst case.

On 4/10/20 11:46 AM, Konstantin Osipov wrote:
> Aleksandr,
>
> just weight the chances and the costs. This optimization locks up up
> to a few hundred megs of memory. The chances that
> slab_get_with_order() is going to oscillate exactly the way you
> describe are minimal: *all* pools must release their fragments of a
> larger slab back to the slab cache. What are the chances of this
> happening at the same time? Even if this happens, the cost of a loop
> which performs slab split/slab merge are minimal. The optimization is
> simply not worth it in terms of price/performance, and causes pains in
> all small installs.