From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Konstantin Osipov <kostja@tarantool.org> Cc: tarantool-patches@freelists.org Subject: [tarantool-patches] Re: [PATCH 1/2] swim: pool IO tasks Date: Mon, 8 Jul 2019 20:31:24 +0200 [thread overview] Message-ID: <35c77ced-50ea-faed-7d41-571020fbbfbb@tarantool.org> (raw) In-Reply-To: <20190708082521.GB24939@atlas> On 08/07/2019 10:25, Konstantin Osipov wrote: > * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [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.
next prev parent reply other threads:[~2019-07-08 18:30 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-05 22:40 [tarantool-patches] [PATCH 0/2] SWIM micro optimizations Vladislav Shpilevoy 2019-07-05 22:40 ` [tarantool-patches] [PATCH 1/2] swim: pool IO tasks Vladislav Shpilevoy 2019-07-05 23:01 ` [tarantool-patches] " Konstantin Osipov 2019-07-06 21:00 ` Vladislav Shpilevoy 2019-07-08 8:25 ` Konstantin Osipov 2019-07-08 18:31 ` Vladislav Shpilevoy [this message] 2019-07-08 21:54 ` Konstantin Osipov 2019-07-08 22:13 ` Vladislav Shpilevoy 2019-07-08 23:08 ` Konstantin Osipov 2019-07-09 19:43 ` Vladislav Shpilevoy 2019-07-09 22:24 ` Konstantin Osipov 2019-07-05 22:40 ` [tarantool-patches] [PATCH 2/2] swim: optimize struct swim_task layout Vladislav Shpilevoy 2019-07-05 23:02 ` [tarantool-patches] " Konstantin Osipov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=35c77ced-50ea-faed-7d41-571020fbbfbb@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH 1/2] swim: pool IO tasks' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox