From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alexander.turenko@tarantool.org>
Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251])
 (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 BB6D946970E
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 30 Jan 2020 14:17:59 +0300 (MSK)
Date: Thu, 30 Jan 2020 14:18:08 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Message-ID: <20200130111808.4f4wgwsvweiu3rxx@tkn_work_nb>
References: <20200129014816.14248-1-bokuno@picodata.io>
 <20200129102813.3gsdeo27lmoh2zsi@tarantool.org>
 <20200129214603.GC31458@atlas>
 <20200130080223.tyta6lti4xsgwqcg@tarantool.org>
 <20200130083437.GD631@atlas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200130083437.GD631@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>
Cc: tarantool-patches@dev.tarantool.org

> <...>

This mailing lists is not about your (or somebody else) emotions around
tarantool. Please, keep them private or send to some other place.

> PS It is of course possible to show that memory fragmentation has
> decreased with this patch by allocating a few objects and looking
> at memory stats. But such test will be fragile and thus bring more
> harm than good. 

You may LD_PRELOAD your own mmap() / munmap() / malloc() / free() (see
[1]) and count number of calls. This way you can look at the behaviour
before and after the patch manually or (maybe) automatically.

Just strace may be okay too, but there should be a case, which will show
that amount of mmap/munmap/malloc/free syscalls is decreased.

[1]: https://tbrindus.ca/correct-ld-preload-hooking-libc/