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 EB6F4297D6 for ; Thu, 11 Apr 2019 09:51:52 -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 4YFb2k3DIkpA for ; Thu, 11 Apr 2019 09:51:52 -0400 (EDT) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (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 A2DDA26939 for ; Thu, 11 Apr 2019 09:51:52 -0400 (EDT) Received: by smtp43.i.mail.ru with esmtpa (envelope-from ) id 1hEa7K-0006nd-SS for tarantool-patches@freelists.org; Thu, 11 Apr 2019 16:51:51 +0300 Date: Thu, 11 Apr 2019 16:51:50 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 1/1] swim: keep encoded round message cached Message-ID: <20190411135150.GA5480@chai> References: <573c97faff11b387566fd449c1d1dcbe3e644351.1554893660.git.v.shpilevoy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573c97faff11b387566fd449c1d1dcbe3e644351.1554893660.git.v.shpilevoy@tarantool.org> 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: tarantool-patches@freelists.org * Vladislav Shpilevoy [19/04/10 17:15]: > During a SWIM round a message is being handed out consisting of > at most 4 sections. Parts of the message change rarely along with > a member attribute update, or with removal of a member. So it is > possible to cache the message and send it during several round > steps in a row. Or even do not rebuild it the whole round. > > Part of #3234 > --- > Branch: https://github.com/tarantool/tarantool/tree/gerold103/gh-3234-swim-cached-msg > Issue: https://github.com/tarantool/tarantool/issues/3234 > > src/lib/swim/swim.c | 24 ++++++++++++++++++++---- > src/lib/swim/swim_io.h | 7 +++++++ > 2 files changed, 27 insertions(+), 4 deletions(-) > > diff --git a/src/lib/swim/swim.c b/src/lib/swim/swim.c > index c64b8df3a..8453295a5 100644 > --- a/src/lib/swim/swim.c > +++ b/src/lib/swim/swim.c > @@ -417,6 +417,13 @@ struct swim { > struct rlist dissemination_queue; > }; > > +/** Reset cached round message on any change of any member. */ > +static inline void > +cached_round_msg_invalidate(struct swim *swim) > +{ > + swim_packet_create(&swim->round_step_task.packet); > +} Are you going to add anything to this method? If not, please get rid of it and inline swim_packet_create() to all relevant places, with an appropriate comment. > swim_on_member_update(struct swim *swim, struct swim_member *member) > { > member->unacknowledged_pings = 0; > + cached_round_msg_invalidate(swim); > swim_register_event(swim, member); Please move the call to cached_round_msg_invalidate() to swim_register_event(). Actually the three members - in_dissemination_queue, status_ttl and cached message - have interdependent life cycle. There are two major events to account for: - whenever you reset status_ttl you need to invalidate the cache and ensure the member is registered in the dissemination queue. - whenever status_ttl drops to zero the member is deleted from the dissemination queue and the cached message can be deleted as well. You have two relevant places for these two events: swim_register_event and swim_decrease_event_ttl(). It should be sufficient to add cache invalidation to them, plus initialize the cache in the constructor and destroy in the destructor. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov