From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kyukhin@tarantool.org>
Received: from smtp40.i.mail.ru (smtp40.i.mail.ru [94.100.177.100])
 (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 5E1D046970E
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 30 Jan 2020 11:02:24 +0300 (MSK)
Date: Thu, 30 Jan 2020 11:02:23 +0300
From: Kirill Yukhin <kyukhin@tarantool.org>
Message-ID: <20200130080223.tyta6lti4xsgwqcg@tarantool.org>
References: <20200129014816.14248-1-bokuno@picodata.io>
 <20200129102813.3gsdeo27lmoh2zsi@tarantool.org>
 <20200129214603.GC31458@atlas>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200129214603.GC31458@atlas>
Subject: Re: [Tarantool-patches] [PATCH] small: unite the oscillation cache
 of all mempools
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: Konstantin Osipov <kostja.osipov@gmail.com>, Maksim Kulis <bokuno@picodata.io>, tarantool-patches@dev.tarantool.org

Hello,

Thanks a lot for your answer!

On 30 янв 00:46, Konstantin Osipov wrote:
> * Kirill Yukhin <kyukhin@tarantool.org> [20/01/29 13:30]:
> > On 29 янв 04:48, Maksim Kulis wrote:
> > > 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
> > 
> > Thanks a lot for your patch. Since the change is performance
> > related, before we start off review process, please provide a
> > testcase (for tarantool or whatever) which will clearly show
> > that there're cases where performance is actually increased.
> > 
> > We won't accept "nice looking" perf patches.
> 
> It's not about performance :)

Okay.

> The patch reduces memory fragmentation quite a bit on small-arena
> systems. Imagine a 1G system with slab_alloc_factor =1.06
> (default). It can easily have up to 50-100 mempools in slab arena,
> each holding up one mslab, up to 100-400MB in total. 
> 
> The whole point of holding up to such mslab is to avoid mmap()
> system call (which is costly) in cases like 
> 
> for (i = 1..10000)
>     mslab_alloc()
>     mslab_free()
> 
> This is allocation scenario is called "oscilation".
> 
> There is no point in it, because there is already a cached mslab in
> slab_cache, and it will be used just fine.
> 
> Maksim should update the CS comment.

Text is fine. But we need a test which will clearly show that
the change will improve something user-visible. If it is not
then it is refactoring and I doubt we'll take it.

--
Regards, Kirill Yukhin