Opened 6 years ago

Last modified 6 years ago

#9255 new bug

BFS uses unaligned memory access for BPlusTree data

Reported by: mmlr Owned by: axeld
Priority: normal Milestone: R1
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

The BPlusTrees in BFS pack their data (key lengths and values) tightly on disk. These structures are then loaded into memory and used directly. Their offsets are calculated, a pointer is formed and the memory is accessed as an array. Since there is no alignment enforced, this can lead to unaligned access of the uint16 key lengths or off_t values. This is illegal from a language point of view, as pointers to a basic type are required to be aligned to the size of that type (so 8 bytes for the off_t). In practice this works on x86 as there unaligned access is just handled silently. However this breaks on processors that have these alignment restrictions like ARM (at least < v6).

As unaligned memory access has to be broken up into multiple bus accesses behind the scenes, they do carry a performance penalty in any case and should therefore be avoided.

To get further with the ARM port I've worked around the issue by implementing getters and setters for the array access and implementing the actual access through memcpy() that does not exhibit the alignment problem. As this introduces a rather large overhead for commonly used functionality in BFS, I am not going to apply this patch. I open this ticket to document the issue and possibly come up with solutions that don't carry as much overhead.

Attachments (1)

0001-Use-memcpy-to-get-and-set-unaligned-BPlusTree-elemen.patch (24.7 KB) - added by mmlr 6 years ago.
Workaround to unaligned memory access using memcpy.

Download all attachments as: .zip

Change History (2)

Changed 6 years ago by mmlr

Workaround to unaligned memory access using memcpy.

comment:1 Changed 6 years ago by axeld

I was actually aware of that issue. However, PPC allows unaligned access as well, so I thought it would work out okay.

Wouldn't it be possible to allow unaligned access in the getter/setter methods if the architecture allows it? While that would make testing harder, it might also be worth the hassle for the extra performance gain.

Note: See TracTickets for help on using tickets.