From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtp30.i.mail.ru (smtp30.i.mail.ru [94.100.177.90])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id D31D14765E0
 for <tarantool-patches@dev.tarantool.org>;
 Mon, 28 Dec 2020 15:10:47 +0300 (MSK)
References: <cover.1608715671.git.mechanik20051988@gmail.com>
 <fa552e40-5ddd-ac82-5dfc-0bb6600ea8bf@tarantool.org>
 <0076A088-8CBC-4238-9EEB-0C73EC516098@hxcore.ol>
 <1608882164.215919067@f40.i.mail.ru>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <2f2fd85a-389c-b957-d8b7-5bb36be6c155@tarantool.org>
Date: Mon, 28 Dec 2020 15:10:45 +0300
MIME-Version: 1.0
In-Reply-To: <1608882164.215919067@f40.i.mail.ru>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [Tarantool-patches] FW: [PATCH] memtx: change small allocator
 behavior
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Evgeny Mekhanik <mechanik20051988@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

Hi! Thanks for the answers!

Now much better, I understood almost everything. The only
issue seems to be with your editor now. You have extra
empty lines after each non-empty line in your emails. Do
you use a web version of mail client?

It should be all fixed if you switch to a plain-text client.
It won't ruin the cites and won't add any extra lines.

>> +                alloc_factor = 1.001;
> 
>  
> 
> 2. I don't see the factor being rounded up in the original code.
> 
> Why did you add it? And why 1.0 is bad?
> 
>  
> Answer:
>  
> Here is a code which rounded up alloc factor in master branch.
>     /*
>      * Correct the user-supplied alloc_factor to ensure that
>      * it actually produces growing object sizes.
>      */
>     if (alloc->step_pool_objsize_max * alloc_factor <
>         alloc->step_pool_objsize_max + STEP_SIZE) {
>         alloc_factor =
>             (alloc->step_pool_objsize_max + STEP_SIZE + 0.5)/
>             alloc->step_pool_objsize_max;
>     }
>     I use gdb to show it:
>     tarantool> box.cfg{slab_alloc_factor = 1.01}
>     2020-12-24 19:22:33.416 [22602] main/103/interactive C> Tarantool 2.7.0-148-gd5a5754a3
>     2020-12-24 19:22:33.416 [22602] main/103/interactive C> log level 5
>     2020-12-24 19:22:33.416 [22602] main/103/interactive I> mapping 268435456 bytes for memtx tuple arena...
>     Breakpoint 1, small_alloc_create (alloc=0x555555cfe788, cache=0x555555cfe530, objsize_min=272,
>                           alloc_factor=1.00999999) at /home/evgeny/MASTER/tarantool/src/lib/small/small/small.c:135
>     135                     alloc_factor =
>     (gdb) n
>     139             alloc->factor = alloc_factor;
>     (gdb) p alloc_factor
>     $1 = 1.032197
>     (gdb)
>     As you can see if you pass slab_alloc_factor < 1.03 it's changed to 1.03. I try 0.01 factor and get the same value.
>     It's code from master branch, now user can pass >= 1.001 factor. We can't use 1.0, because we need increment to pool size.

Ok, now I see, thanks.