From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) (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 68B9946970E for ; Thu, 6 Feb 2020 19:26:16 +0300 (MSK) Received: by mail-lf1-f67.google.com with SMTP id y19so4521447lfl.9 for ; Thu, 06 Feb 2020 08:26:16 -0800 (PST) Date: Thu, 6 Feb 2020 19:26:14 +0300 From: Konstantin Osipov Message-ID: <20200206162614.GI3311@atlas> References: <1580986257.247207517@f306.i.mail.ru> <20200206142934.GB3311@atlas> <1581005653.630549653@f491.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1581005653.630549653@f491.i.mail.ru> Subject: Re: [Tarantool-patches] [PATCH v3 2/2] memtx: allow quota overuse for truncation and deletion List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ilya Kosarev Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Ilya Kosarev [20/02/06 19:15]: > > From memtx_tuple_new() we call smalloc(). In case it is calling > mempool_alloc(), we are passing the pool from memtx->alloc, chosen > depending on it's size. Later this tuple may be deleted. Then smfree() > is called, which uses mempool_find() to acquire the pool we want to > free. > In case we are using some other specific pool, current mempool_find() > won't be able to find it. This means we need to process this case > explicitly and it seems to add noticeable unjustified complexity to the > code. Why do you need to use a special pool? Can't you reserve a single slab in memtx_arena, just like memtx reserves extents now, and allow use of this slab for any pool *only* when processing truncate? -- Konstantin Osipov, Moscow, Russia https://scylladb.com