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 3EE9820177 for ; Mon, 8 Jul 2019 18:11:57 -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 K2LlAbS4JHsI for ; Mon, 8 Jul 2019 18:11:57 -0400 (EDT) Received: from smtp52.i.mail.ru (smtp52.i.mail.ru [94.100.177.112]) (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 F1E052014D for ; Mon, 8 Jul 2019 18:11:56 -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> <35c77ced-50ea-faed-7d41-571020fbbfbb@tarantool.org> <20190708215432.GB7873@atlas> From: Vladislav Shpilevoy Message-ID: <050a79f5-847a-f184-2197-87cc789cfeab@tarantool.org> Date: Tue, 9 Jul 2019 00:13:13 +0200 MIME-Version: 1.0 In-Reply-To: <20190708215432.GB7873@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 >>>> >>>>> >>>>> 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. > > OK, wait a second. I thought you're going to have a single task > instance for each member. Which means a couple of dozen instances > even in a two node cluster. Am I wrong? > Yes, you misunderstood something. This is the whole point of this commit - make number of tasks not depending on a number of members. On the master branch now the number of tasks per SWIM is linear of cluster size - it is terrible. Both 1 and 2 tasks per member are linear. But network load per one instance does not depend on number of members, so we can make number of tasks independent from cluster size. I am trying to reuse a small set of tasks for all members of one instance. Just imagine - a SWIM instance knows about 500 members, and manages to work with them using just 2-10 messages at once.