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 60A5020C92 for ; Tue, 9 Jul 2019 15:42:02 -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 jvUikmUSMbXl for ; Tue, 9 Jul 2019 15:42:02 -0400 (EDT) Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (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 9BAF820C8F for ; Tue, 9 Jul 2019 15:42:01 -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> <050a79f5-847a-f184-2197-87cc789cfeab@tarantool.org> <20190708230807.GB11128@atlas> From: Vladislav Shpilevoy Message-ID: <743246c0-7780-2c1e-06d7-1c86d17140e6@tarantool.org> Date: Tue, 9 Jul 2019 21:43:05 +0200 MIME-Version: 1.0 In-Reply-To: <20190708230807.GB11128@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 The patchset is pushed to the master. On 09/07/2019 01:08, Konstantin Osipov wrote: > * Vladislav Shpilevoy [19/07/09 01:13]: >> 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. > > ok, then a mempool is an overkill for sure. >