From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ED45846970E for ; Thu, 30 Jan 2020 16:05:49 +0300 (MSK) Date: Thu, 30 Jan 2020 16:05:58 +0300 From: Alexander Turenko Message-ID: <20200130130558.oimnahjmnecmvcpt@tkn_work_nb> 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> <20200130122308.GB11018@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200130122308.GB11018@atlas> 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: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org On Thu, Jan 30, 2020 at 03:23:08PM +0300, Konstantin Osipov wrote: > * 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. The processes were not better (at least) when you was manager here. Now you don't seat near us and have even less necessary context. Yep, I personally think that we should ignore your suggestions in this area. This is not a viewpoint of the company, it is my personal opinion. And since DDL tests are entirely unrelated to this thread, it does not look as feedback, whose goal is to suggest us to raise priority of this issue. It is either emotions or attempt to present us is an unfavourable light (because of, again, emotions or business needs of your tarantool consulting, but likely the former). Sorry if it looks offending. (I propose to don't continue this particular discussion, at least here.) > > > > 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. This is one example of the bad processes that we had when you did work with us: 'Kostja said LGTM, so proper testing is not necessary'. > > 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. Maybe. Black box testing is not always enough. > > Meanwhile, if you wish to ignore it because it doesn't come with a > testing infrastructure - it's up to you. I had asked for a workload that can show gains under manual run at least. Not a testing infrastructure. > > > > it's worth it, neither for this patch > > -- > Konstantin Osipov, Moscow, Russia