Tarantool development patches archive
 help / color / mirror / Atom feed
From: Aleksandr Lyapunov <alyapunov@tarantool.org>
To: bokuno@picodata.io, tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] small: unite the oscillation cache of all mempools
Date: Fri, 10 Apr 2020 11:36:34 +0300	[thread overview]
Message-ID: <4514cc23-b201-f12a-20b7-755dbfe24653@tarantool.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

Thanks for the patch!

As I see mempool::spare was implemented in order to prevent
dangerous oscillation that is different to oscillation of
the-largest-size slab in slab_cache.
Allocation of a slab in slab_cache for mempool can cause slab
splitting routine that could be not so fast as one can expect.
In the edge case the-largest-size slab is split in two parts,
one of the parts is slit again ans so on, up to 16 iterations.
Releasing such a slab will cause a reverse procedure - merging
of all those slabs into the largest. And if we don't store
spare slab in the mempool, simple allocation/deallocation of
one and only item can be deadly slow. Imagine a loop with that
workout.

So I'm sure that we need mempool::spare optimization in order
to make mempool allocation performance more predictable.

Sorry, thanks btw.

> The task is to unite the oscillation cache of all mempools.
> In the function slab_put_with_order() we check if there is any
> slab of the largest size except the current one, in order to
> avoid oscillation.
> https://github.com/tarantool/small/blob/master/small/slab_cache.c#L349
>
> ---
>   small/mempool.c | 22 ++++------------------
>   small/mempool.h |  6 ------
>   2 files changed, 4 insertions(+), 24 deletions(-)
>
> diff --git a/small/mempool.c b/small/mempool.c
> index b20a416..54bd58d 100644
> --- a/small/mempool.c
> +++ b/small/mempool.c
> @@ -126,18 +126,9 @@ mslab_free(struct mempool *pool, struct mslab *slab, void *ptr)
>   		}
>   		mslab_tree_remove(&pool->hot_slabs, slab);
>   		slab->in_hot_slabs = false;
> -		if (pool->spare > slab) {
> -			slab_list_del(&pool->slabs, &pool->spare->slab,
> -				      next_in_list);
> -			slab_put_with_order(pool->cache, &pool->spare->slab);
> -			pool->spare = slab;
> -		 } else if (pool->spare) {
> -			 slab_list_del(&pool->slabs, &slab->slab,
> -				       next_in_list);
> -			 slab_put_with_order(pool->cache, &slab->slab);
> -		 } else {
> -			 pool->spare = slab;
> -		 }
> +		slab_list_del(&pool->slabs, &slab->slab,
> +			      next_in_list);
> +		slab_put_with_order(pool->cache, &slab->slab);
>   	}
>   }
>   
> @@ -153,7 +144,6 @@ mempool_create_with_order(struct mempool *pool, struct slab_cache *cache,
>   	mslab_tree_new(&pool->hot_slabs);
>   	pool->first_hot_slab = NULL;
>   	rlist_create(&pool->cold_slabs);
> -	pool->spare = NULL;
>   	pool->objsize = objsize;
>   	pool->slab_order = order;
>   	/* Total size of slab */
> @@ -179,11 +169,7 @@ mempool_alloc(struct mempool *pool)
>   {
>   	struct mslab *slab = pool->first_hot_slab;
>   	if (slab == NULL) {
> -		if (pool->spare) {
> -			slab = pool->spare;
> -			pool->spare = NULL;
> -
> -		} else if ((slab = (struct mslab *)
> +		if ((slab = (struct mslab *)
>   			    slab_get_with_order(pool->cache,
>   						pool->slab_order))) {
>   			mslab_create(slab, pool);
> diff --git a/small/mempool.h b/small/mempool.h
> index 15d85a4..9d0e162 100644
> --- a/small/mempool.h
> +++ b/small/mempool.h
> @@ -149,12 +149,6 @@ struct mempool
>   	 * tree is empty or the allocator runs out of memory.
>   	 */
>   	struct rlist cold_slabs;
> -	/**
> -	 * A completely empty slab which is not freed only to
> -	 * avoid the overhead of slab_cache oscillation around
> -	 * a single element allocation.
> -	 */
> -	struct mslab *spare;
>   	/**
>   	 * The size of an individual object. All objects
>   	 * allocated on the pool have the same size.
> -- 
> 2.17.1


[-- Attachment #2: Type: text/html, Size: 3784 bytes --]

             reply	other threads:[~2020-04-10  8:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-10  8:36 Aleksandr Lyapunov [this message]
     [not found] ` <CAPZPwLrNbdCzX7LR+_P8xrZ+unDpw-k2EP1Jj5mAsGOTWz2frA@mail.gmail.com>
2020-04-10 12:44   ` Aleksandr Lyapunov
  -- strict thread matches above, loose matches on Subject: below --
2020-01-29  1:48 Maksim Kulis
2020-01-29 10:28 ` Kirill Yukhin
2020-01-29 21:46   ` Konstantin Osipov
2020-01-30  8:02     ` Kirill Yukhin
2020-01-30  8:34       ` Konstantin Osipov
2020-01-30 11:18         ` Alexander Turenko
2020-01-30 12:23           ` Konstantin Osipov
2020-01-30 13:05             ` Alexander Turenko
2020-01-30 14:47               ` Konstantin Osipov
2020-01-30 12:20         ` Kirill Yukhin
2020-01-30 12:36           ` Konstantin Osipov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4514cc23-b201-f12a-20b7-755dbfe24653@tarantool.org \
    --to=alyapunov@tarantool.org \
    --cc=bokuno@picodata.io \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] small: unite the oscillation cache of all mempools' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox