Tarantool development patches archive
 help / color / mirror / Atom feed
From: Konstantin Osipov <kostja.osipov@gmail.com>
To: Kirill Yukhin <kyukhin@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] small: unite the oscillation cache of all mempools
Date: Thu, 30 Jan 2020 15:36:42 +0300	[thread overview]
Message-ID: <20200130123642.GC11018@atlas> (raw)
In-Reply-To: <20200130122011.shdmnyp7g7xg7igg@tarantool.org>

* Kirill Yukhin <kyukhin@tarantool.org> [20/01/30 15:23]:
> > 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.
> 
> Small library is core of core. This is one of essential parts.
> Our team @ MRG doesn't have a guy (or girl) who has enough
> expertise to take responsibility and to accept such change
> without a test.
> 
> The patch looks outstanding, but to start off a review process,
> we need a test, sorry.

OK, I get it, this is a fair response at last. 

We can let the patch cook on a fork and re-submit it after we
learn it's safe.

You can also run it through bench.tarantool.org as soon as it's
functioning.

The patch is only removing the code, so it should be pretty safe. 
It is affecting some real people from @tarantoolru chat.

The test you suggest will not test any side-line impact of the
patch (if there was any), since it will only allocate a few bytes
and then free them. So I really think such test is useless.

I guess a good test would be a randomized longevity test 
with some integral quality metrics, like allocations/second or
average memory fragmentation. We don't have such test yet.

If things go as planned, Maksim (with my help) will work on log
structured allocator for small, and we might construct such test
in scope of this work.

-- 
Konstantin Osipov, Moscow, Russia

  reply	other threads:[~2020-01-30 14:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2020-04-10  8:36 Aleksandr Lyapunov
     [not found] ` <CAPZPwLrNbdCzX7LR+_P8xrZ+unDpw-k2EP1Jj5mAsGOTWz2frA@mail.gmail.com>
2020-04-10 12:44   ` Aleksandr Lyapunov

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=20200130123642.GC11018@atlas \
    --to=kostja.osipov@gmail.com \
    --cc=kyukhin@tarantool.org \
    --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