From: "Timur Safin" <tsafin@tarantool.org>
To: 'Vladislav Shpilevoy' <v.shpilevoy@tarantool.org>,
tarantool-patches@dev.tarantool.org, alyapunov@tarantool.org,
korablev@tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v2 08/10] tuple: use unaligned store-load for field map
Date: Thu, 28 May 2020 23:22:59 +0300 [thread overview]
Message-ID: <049901d6352d$c7b42240$571c66c0$@tarantool.org> (raw)
In-Reply-To: <34f402cf20e60a7255c25d261a2bc409e762bf71.1590622225.git.v.shpilevoy@tarantool.org>
Yup!
LGTM!
: -----Original Message-----
: From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
: Sent: Thursday, May 28, 2020 2:32 AM
: To: tarantool-patches@dev.tarantool.org; alyapunov@tarantool.org;
: korablev@tarantool.org; tsafin@tarantool.org
: Subject: [PATCH v2 08/10] tuple: use unaligned store-load for field map
:
: A tuple can have a field map. It is an array of uint32_t values,
: stored right after 'struct tuple' object in the same memory block.
:
: 'struct tuple' is 10 byte size, and is aligned by 4 bytes (even
: though it is 'PACKED', so does not need an alignment). It means,
: that field map is stored by an address like this: 4*N + 10.
:
: This address is never aligned by 4, needed for uint32_t field map
: array. So the array members should be accessed using operations
: aware of unaligned nature of the addresses.
:
: Unfortunately, it is impossible to make the field map aligned,
: because that requires + 2 bytes for each tuple. It is unaffordable
: luxury, since tuple count can be millions and even billions. Every
: new byte may result in gigabytes of memory in a cluster.
:
: The patch makes field map accessed using unaligned store-load
: operations.
:
: Part of #4609
: ---
: src/box/field_map.c | 13 +++++++++----
: src/box/field_map.h | 21 ++++++++++++---------
: 2 files changed, 21 insertions(+), 13 deletions(-)
:
: diff --git a/src/box/field_map.c b/src/box/field_map.c
: index 5f4661941..dc903115e 100644
: --- a/src/box/field_map.c
: +++ b/src/box/field_map.c
: @@ -101,16 +101,21 @@ field_map_build(struct field_map_builder *builder,
: char *buffer)
: (uint32_t *)(buffer + field_map_build_size(builder));
: char *extent_wptr = buffer;
: for (int32_t i = -1; i >= -(int32_t)builder->slot_count; i--) {
: + /*
: + * Can not access field_map as a normal uint32
: + * array because its alignment may be < 4 bytes.
: + * Need to use unaligned store-load operations
: + * explicitly.
: + */
: if (!builder->slots[i].has_extent) {
: - field_map[i] = builder->slots[i].offset;
: + store_u32(&field_map[i], builder->slots[i].offset);
: continue;
: }
: struct field_map_builder_slot_extent *extent =
: builder->slots[i].extent;
: /** Retrive memory for the extent. */
: - field_map[i] =
: - (uint32_t)((char *)extent_wptr - (char *)field_map);
: - *(uint32_t *)extent_wptr = extent->size;
: + store_u32(&field_map[i], extent_wptr - (char *)field_map);
: + store_u32(extent_wptr, extent->size);
: uint32_t extent_offset_sz = extent->size * sizeof(uint32_t);
: memcpy(&((uint32_t *) extent_wptr)[1], extent->offset,
: extent_offset_sz);
: diff --git a/src/box/field_map.h b/src/box/field_map.h
: index a1a5a9dba..d8ef726a1 100644
: --- a/src/box/field_map.h
: +++ b/src/box/field_map.h
: @@ -33,6 +33,7 @@
: #include <assert.h>
: #include <stdint.h>
: #include <stddef.h>
: +#include "bit/bit.h"
:
: struct region;
: struct field_map_builder_slot;
: @@ -151,20 +152,22 @@ static inline uint32_t
: field_map_get_offset(const uint32_t *field_map, int32_t offset_slot,
: int multikey_idx)
: {
: - uint32_t offset;
: - if (multikey_idx != MULTIKEY_NONE &&
: - (int32_t) field_map[offset_slot] < 0) {
: + /*
: + * Can not access field_map as a normal uint32 array
: + * because its alignment may be < 4 bytes. Need to use
: + * unaligned store-load operations explicitly.
: + */
: + uint32_t offset = load_u32(&field_map[offset_slot]);
: + if (multikey_idx != MULTIKEY_NONE && (int32_t)offset < 0) {
: /**
: * The field_map extent has the following
: * structure: [size=N|slot1|slot2|..|slotN]
: */
: - uint32_t *extent = (uint32_t *)((char *)field_map +
: - (int32_t)field_map[offset_slot]);
: - if ((uint32_t)multikey_idx >= extent[0])
: + const uint32_t *extent = (const uint32_t *)
: + ((const char *)field_map + (int32_t)offset);
: + if ((uint32_t)multikey_idx >= load_u32(&extent[0]))
: return 0;
: - offset = extent[multikey_idx + 1];
: - } else {
: - offset = field_map[offset_slot];
: + offset = load_u32(&extent[multikey_idx + 1]);
: }
: return offset;
: }
: --
: 2.21.1 (Apple Git-122.3)
next prev parent reply other threads:[~2020-05-28 20:23 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 23:32 [Tarantool-patches] [PATCH v2 00/10] Sanitize unaligned access Vladislav Shpilevoy
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 01/10] small: sanitized rlist and new region API Vladislav Shpilevoy
2020-05-28 20:41 ` Timur Safin
2020-05-28 22:56 ` Vladislav Shpilevoy
2020-06-08 23:01 ` Vladislav Shpilevoy
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 10/10] xrow: use unaligned store operation in xrow_to_iovec() Vladislav Shpilevoy
2020-05-28 20:20 ` Timur Safin
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 02/10] cmake: ignore warnings on alignof() and offsetof() Vladislav Shpilevoy
2020-05-28 20:18 ` Timur Safin
2020-05-29 6:24 ` Kirill Yukhin
2020-05-29 22:34 ` Vladislav Shpilevoy
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 03/10] cmake: add option ENABLE_UB_SANITIZER Vladislav Shpilevoy
2020-05-28 20:42 ` Timur Safin
2020-05-29 8:53 ` Sergey Bronnikov
2020-05-29 22:36 ` Vladislav Shpilevoy
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 04/10] crc32: align memory access Vladislav Shpilevoy
2020-05-28 20:11 ` Timur Safin
2020-05-28 23:23 ` Vladislav Shpilevoy
2020-05-28 23:32 ` Timur Safin
2020-06-08 22:33 ` Vladislav Shpilevoy
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 05/10] sql: make BtCursor's memory aligned Vladislav Shpilevoy
2020-05-28 20:20 ` Timur Safin
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 06/10] region: use aligned allocations where necessary Vladislav Shpilevoy
2020-05-28 20:35 ` Timur Safin
2020-05-28 23:07 ` Vladislav Shpilevoy
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 07/10] vinyl: align statements and bps tree extents Vladislav Shpilevoy
2020-05-28 20:38 ` Timur Safin
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 08/10] tuple: use unaligned store-load for field map Vladislav Shpilevoy
2020-05-28 20:22 ` Timur Safin [this message]
2020-05-27 23:32 ` [Tarantool-patches] [PATCH v2 09/10] port: make port_c_entry not PACKED Vladislav Shpilevoy
2020-05-28 20:42 ` Timur Safin
2020-06-03 21:27 ` [Tarantool-patches] [PATCH v2 00/10] Sanitize unaligned access Vladislav Shpilevoy
2020-06-08 22:33 ` Vladislav Shpilevoy
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='049901d6352d$c7b42240$571c66c0$@tarantool.org' \
--to=tsafin@tarantool.org \
--cc=alyapunov@tarantool.org \
--cc=korablev@tarantool.org \
--cc=tarantool-patches@dev.tarantool.org \
--cc=v.shpilevoy@tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH v2 08/10] tuple: use unaligned store-load for field map' \
/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