[tarantool-patches] [PATCH 1/1] swim: optimize struct swim memory layout

[tarantool-patches] [PATCH 1/1] swim: optimize struct swim memory layout

[Vladislav Shpilevoy]

The same problem that occured with struct swim_member, has
happened with struct swim - it contains a huge structure right in
the middle, struct swim_task. It consumes 1.5Kb and obviously
splits the most accessible struct swim attributes into multiple
cache lines.

This patch moves struct swim_task to the bottom as well as other
members, related to dissemination component.
---
Branch: https://github.com/tarantool/tarantool/tree/gerold103/struct-swim-memory-layout

 src/lib/swim/swim.c | 58 ++++++++++++++++++++++++---------------------
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/src/lib/swim/swim.c b/src/lib/swim/swim.c
index e59e667fd..746106657 100644
--- a/src/lib/swim/swim.c
+++ b/src/lib/swim/swim.c
@@ -400,33 +400,6 @@ struct swim {
 	 * status.
 	 */
 	struct swim_member *self;
-	/**
-	 * Members to which a message should be sent next during
-	 * this round.
-	 */
-	struct rlist round_queue;
-	/** Generator of round step events. */
-	struct ev_timer round_tick;
-	/**
-	 * Single round step task. It is impossible to have
-	 * multiple round steps in the same SWIM instance at the
-	 * same time, so it is single and preallocated per SWIM
-	 * instance. Note, that the task's packet once built at
-	 * the beginning of a round is reused during the round
-	 * without rebuilding on each step. But packet rebuild can
-	 * be triggered by any update of any member.
-	 */
-	struct swim_task round_step_task;
-	/**
-	 * True if a packet in the round step task is still valid
-	 * and can be resent on a next round step.
-	 */
-	bool is_round_packet_valid;
-	/**
-	 * Preallocated buffer to store shuffled members here at
-	 * the beginning of each round.
-	 */
-	struct swim_member **shuffled;
 	/**
 	 * Scheduler of output requests, receiver of incoming
 	 * ones.
@@ -470,6 +443,37 @@ struct swim {
 	 * as long as the event TTD is non-zero.
 	 */
 	struct rlist dissemination_queue;
+	/**
+	 * Members to which a message should be sent next during
+	 * this round.
+	 */
+	struct rlist round_queue;
+	/** Generator of round step events. */
+	struct ev_timer round_tick;
+	/**
+	 * True if a packet in the round step task is still valid
+	 * and can be resent on a next round step.
+	 */
+	bool is_round_packet_valid;
+	/**
+	 * Preallocated buffer to store shuffled members here at
+	 * the beginning of each round.
+	 */
+	struct swim_member **shuffled;
+	/**
+	 * Single round step task. It is impossible to have
+	 * multiple round steps in the same SWIM instance at the
+	 * same time, so it is single and preallocated per SWIM
+	 * instance. Note, that the task's packet once built at
+	 * the beginning of a round is reused during the round
+	 * without rebuilding on each step. But packet rebuild can
+	 * be triggered by any update of any member.
+	 *
+	 * Keep this structure at the bottom - it is huge and
+	 * should not split other attributes into different cache
+	 * lines.
+	 */
+	struct swim_task round_step_task;
 };
 
 /**
-- 
2.20.1 (Apple Git-117)

[tarantool-patches] Re: [PATCH 1/1] swim: optimize struct swim memory layout

[Konstantin Osipov]

* Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/04/26 22:11]:
> The same problem that occured with struct swim_member, has
> happened with struct swim - it contains a huge structure right in
> the middle, struct swim_task. It consumes 1.5Kb and obviously
> splits the most accessible struct swim attributes into multiple
> cache lines.

OK to push.


-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32

[tarantool-patches] Re: [PATCH 1/1] swim: optimize struct swim memory layout

[Vladislav Shpilevoy]

Pushed into the master.

On 26/04/2019 22:13, Konstantin Osipov wrote:
> * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/04/26 22:11]:
>> The same problem that occured with struct swim_member, has
>> happened with struct swim - it contains a huge structure right in
>> the middle, struct swim_task. It consumes 1.5Kb and obviously
>> splits the most accessible struct swim attributes into multiple
>> cache lines.
> 
> OK to push.
> 
> 
> -- 
> Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
>