From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (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 0829846970E for ; Thu, 30 Jan 2020 15:23:09 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id o11so3099544ljc.6 for ; Thu, 30 Jan 2020 04:23:09 -0800 (PST) Date: Thu, 30 Jan 2020 15:23:08 +0300 From: Konstantin Osipov Message-ID: <20200130122308.GB11018@atlas> References: <20200129014816.14248-1-bokuno@picodata.io> <20200129102813.3gsdeo27lmoh2zsi@tarantool.org> <20200129214603.GC31458@atlas> <20200130080223.tyta6lti4xsgwqcg@tarantool.org> <20200130083437.GD631@atlas> <20200130111808.4f4wgwsvweiu3rxx@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200130111808.4f4wgwsvweiu3rxx@tkn_work_nb> 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: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org * Alexander Turenko [20/01/30 14:21]: > This mailing lists is not about your (or somebody else) emotions around > tarantool. Please, keep them private or send to some other place. Is it OK to laugh, or you're going to ban for a joke? And anyway, it was not about emotions. I've given you feedback about the quality of the process - you can try to address it or dismiss, like you've just did, and like you did a few times before, it's of course up to you. > > 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/ As I said, I don't think this tiny patch justifies it. The patch fixes a real issue that multiple users have hit. If bench.tarantool.org was operational, it would be easy to see if the patch has any impact on performance. This is the only remotely relevant concern here. Meanwhile, if you wish to ignore it because it doesn't come with a testing infrastructure - it's up to you. it's worth it, neither for this patch -- Konstantin Osipov, Moscow, Russia