From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (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 0B5844696C3 for ; Fri, 10 Apr 2020 15:44:16 +0300 (MSK) References: <4514cc23-b201-f12a-20b7-755dbfe24653@tarantool.org> From: Aleksandr Lyapunov Message-ID: <8938a5ca-a4af-3275-96d0-1848b98fb683@tarantool.org> Date: Fri, 10 Apr 2020 15:44:15 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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 Yes, there is a case when we waste lots of memory. But I think that the case case of split/merge hammering is not so impossible. I guess there some workloads when tuple lifetime is very shot, perhaps queue. If we add to the workload use of tuples of different sizes, from dozens of small slabs, we'll get a case where small mempools very frequently switch between empty and non-empty states. And if the average number of non-empty small mempools is around some magic numbers (power of two if all slabs have the same size) then there could some significant performance difference. This case is not frequent though, but we should not degrade worst case. On 4/10/20 11:46 AM, Konstantin Osipov wrote: > Aleksandr, > > just weight the chances and the costs. This optimization locks up up > to a few hundred megs of memory. The chances that > slab_get_with_order() is going to oscillate exactly the way you > describe are minimal: *all* pools must release their fragments of a > larger slab back to the slab cache. What are the chances of this > happening at the same time? Even if this happens, the cost of a loop > which performs slab split/slab merge are minimal. The optimization is > simply not worth it in terms of price/performance, and causes pains in > all small installs.