From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7519222C10 for ; Mon, 8 Jul 2019 14:30:11 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7y8CIlnRhCg for ; Mon, 8 Jul 2019 14:30:11 -0400 (EDT) Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id A98B822CA2 for ; Mon, 8 Jul 2019 14:30:10 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH 1/2] swim: pool IO tasks References: <20190705230136.GD30966@atlas> <609c7e7b-d8f7-413b-752c-94034bfd689b@tarantool.org> <20190708082521.GB24939@atlas> From: Vladislav Shpilevoy Message-ID: <35c77ced-50ea-faed-7d41-571020fbbfbb@tarantool.org> Date: Mon, 8 Jul 2019 20:31:24 +0200 MIME-Version: 1.0 In-Reply-To: <20190708082521.GB24939@atlas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Konstantin Osipov Cc: tarantool-patches@freelists.org On 08/07/2019 10:25, Konstantin Osipov wrote: > * Vladislav Shpilevoy [19/07/07 16:28]: >>>> +static struct stailq swim_task_pool; >>>> +/** Number of pooled tasks. */ >>>> +static int swim_task_pool_size = 0; >>> >>> These should be thread-local. >> >> Why? SWIM works in one thread, these values are never accessed >> from another one. They would be just copied for each thread and >> unused in all but one. > > What happens if I create multiple instances of swim library in > multiple threads? These instances will try to concurrently access > these members without mutexes. How is it possible? SWIM works in TX only. You just can't create it another thread. It is literally impossible. Even if someday it will work in another thread, still all the SWIMs will work in one thread. So in future we won't allow to scatter SWIMs among multiple threads as well. With the same reasoning we would need to make thread-local all global on_replace triggers like on_replace_vinyl_deferred_delete just in case if in future Vinyl will do DML/DQL in multiple threads. But why should we do that now? I do not understand. >> >>> >>> Why not use mempool? >>> >>> >> >> Because 1) it is an overkill, 2) I don't want to depend on >> slab allocator, 3) it just does not fit this case, according >> to mempool description from mempool.h: >> >> "Good for allocating tons of small objects of the same size.". > > It is also quite decent for allocating many fairly large objects. > The key point is that the object is of the same size. You can set > up mempool the right slab size, and in this case it will do > exactly what you want. > And again - 'many' usually won't be the case. We will have 0-2 SWIMs in 99% of cases. One internal SWIM for box, and one external created by a user. Barely we will have more than 10 cached tasks. But ok, as you wish. This place is not as critical for me as thread locality of the pool. At least we reuse existing code. Thread locality still looks pointless waste of memory for me.