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 790C74765E0 for ; Tue, 22 Dec 2020 16:28:32 +0300 (MSK) References: <20201211153724.7575-1-i.kosarev@tarantool.org> <1608162239.973321901@f42.i.mail.ru> <7787de2a-ba8d-66bd-d52b-c0c672d6e810@tarantool.org> <1608574523.582576002@f340.i.mail.ru> From: Vladislav Shpilevoy Message-ID: <99a08336-665b-6973-33e8-b49e44dc7d74@tarantool.org> Date: Tue, 22 Dec 2020 14:28:30 +0100 MIME-Version: 1.0 In-Reply-To: <1608574523.582576002@f340.i.mail.ru> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Tarantool-patches] [PATCH] memtx: allow quota overuse for truncation List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ilya Kosarev Cc: tarantool-patches@dev.tarantool.org > Also I don't understand why can't you do that on the slab arena > level. Start allocating only 'huge' slabs if the quota is full, but > disabled. > > Yes, allocation in case of out of quota can be done on more > internal level. > But the problem is exactly in freeing you mentioned further. > We need to free in the right way: If we are allocating with > mempool, we need to use mempool_find() properly, while > if we are allocating ‘huge’ slab, we need to free it accordingly. > So the information about the allocation has to be stored > somehow in case we are going to alter it depending on the > current state. I don’t see convenient place where we can store > it, looks like it will be even worse to store such information > in struct tuple itself. I don't understand why do you need to store any info. Huge slabs existed and were freed before your patch, and all worked fine here. How are they found and freed with quota enabled?