From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 90ACE46970E for ; Thu, 30 Jan 2020 17:34:24 +0300 (MSK) Received: by mail-lf1-f68.google.com with SMTP id f24so2452842lfh.3 for ; Thu, 30 Jan 2020 06:34:24 -0800 (PST) Date: Thu, 30 Jan 2020 15:36:42 +0300 From: Konstantin Osipov Message-ID: <20200130123642.GC11018@atlas> References: <20200129014816.14248-1-bokuno@picodata.io> <20200129102813.3gsdeo27lmoh2zsi@tarantool.org> <20200129214603.GC31458@atlas> <20200130080223.tyta6lti4xsgwqcg@tarantool.org> <20200130083437.GD631@atlas> <20200130122011.shdmnyp7g7xg7igg@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200130122011.shdmnyp7g7xg7igg@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] small: unite the oscillation cache of all mempools List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kirill Yukhin Cc: tarantool-patches@dev.tarantool.org * Kirill Yukhin [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