On 2019/6/18 下午10:15, David Sterba wrote: > We don't use the plain key for any on-disk operations so there's no > requirement for the member order. As the offset is a u64 that should be > on an 8byte aligned address, this can generate ineffective code on > strict alignment architectures and can potentially hurt even on others > (cross-cacheline access). > > The resulting asm code on x86_64 only differes in the offset, no significant > change in size of the object size. > > The alignment of the structure is unchanged. > > Signed-off-by: David Sterba <dste...@suse.com> > --- > include/uapi/linux/btrfs_tree.h | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h > index aff1356c2bb8..9ca7adcf3b7f 100644 > --- a/include/uapi/linux/btrfs_tree.h > +++ b/include/uapi/linux/btrfs_tree.h > @@ -342,10 +342,17 @@ struct btrfs_disk_key { > __le64 offset; > } __attribute__ ((__packed__)); > > +/* > + * NOTE: this structure does not match the on-disk format of key and must be > + * converted with the right helpers. The btrfs_key is for in-memory use and > the > + * members are reordered for better alignment. It's still packed as it's > never > + * used in arrays and the extra alignment would consume stack space in > + * functions. > + */ > struct btrfs_key { > __u64 objectid; > - __u8 type; > __u64 offset; > + __u8 type; > } __attribute__ ((__packed__));
And why not remove the packed attribute? Thanks, Qu > > struct btrfs_dev_item { >
signature.asc
Description: OpenPGP digital signature