From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (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 9D0614765E0 for ; Tue, 22 Dec 2020 17:22:07 +0300 (MSK) References: <20201211153724.7575-1-i.kosarev@tarantool.org> <1608574523.582576002@f340.i.mail.ru> <99a08336-665b-6973-33e8-b49e44dc7d74@tarantool.org> <1608646450.857716758@f406.i.mail.ru> From: Vladislav Shpilevoy Message-ID: Date: Tue, 22 Dec 2020 15:22:06 +0100 MIME-Version: 1.0 In-Reply-To: <1608646450.857716758@f406.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 On 22.12.2020 15:14, Ilya Kosarev wrote: > Вторник, 22 декабря 2020, 16:28 +03:00 от Vladislav Shpilevoy : >   > > 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? > > Proper huge slabs are actually huge and mempool_find() thus > returns NULL for them and they are freed properly. Here we are > allocating «huge» slabs of the size which is the size of actual > truncate tuples, and it is not really huge. Thus we need specific > info to free it in the right way. Ok, why can't you use the existing 'huge' slabs and not re-invent your own ones?