From: Pranjal Shrivastava <praan@google.com>
To: Will Deacon <will@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Mostafa Saleh <smostafa@google.com>,
Nicolin Chen <nicolinc@nvidia.com>,
iommu@lists.linux.dev, Jason Gunthorpe <jgg@nvidia.com>,
Daniel Mentz <danielmentz@google.com>
Subject: Re: [PATCH v4 1/3] iommu/arm-smmu-v3: Introduce struct arm_smmu_event
Date: Thu, 24 Oct 2024 17:02:08 +0000 [thread overview]
Message-ID: <Zxp9kHerb-ln4ioO@google.com> (raw)
In-Reply-To: <20241024131147.GG30704@willie-the-truck>
On Thu, Oct 24, 2024 at 02:11:48PM +0100, Will Deacon wrote:
> On Fri, Oct 18, 2024 at 06:00:20PM +0000, Pranjal Shrivastava wrote:
> > +struct arm_smmu_event {
> > + struct arm_smmu_device *smmu;
> > + u8 id;
> > + u8 class;
> > + u16 stag;
> > + u32 sid;
> > + u32 ssid;
> > + u64 iova;
> > + u64 ipa;
> > + u64 raw[EVTQ_ENT_DWORDS];
> > + bool stall;
> > + bool ssid_valid;
> > + bool privileged;
> > + bool instruction;
> > + bool s2;
> > + bool read;
> > +};
>
> minor nit, but it might be worth seeing what pahole says about the
> layout of this structure in case you've got a bunch of wasted padding
> thanks to the mixed-size fields.
I ran pahole with this, looks like there's only one 4-byte hole but the
cacheline aligment is bad (for a 64-byte cacheline):
struct arm_smmu_event {
const char * master_name; /* 0 8 */
struct arm_smmu_device * smmu; /* 8 8 */
struct device * dev; /* 16 8 */
u8 id; /* 24 1 */
u8 class; /* 25 1 */
u16 stag; /* 26 2 */
u32 sid; /* 28 4 */
u32 ssid; /* 32 4 */
/* XXX 4 bytes hole, try to pack */
u64 iova; /* 40 8 */
u64 ipa; /* 48 8 */
u64 raw[4]; /* 56 32 */
/* --- cacheline 1 boundary (64 bytes) was 24 bytes ago --- */
bool stall; /* 88 1 */
bool ssid_valid; /* 89 1 */
bool privileged; /* 90 1 */
bool instruction; /* 91 1 */
bool s2; /* 92 1 */
bool read; /* 93 1 */
bool ttrnw; /* 94 1 */
bool ttrnw_valid; /* 95 1 */
/* size: 96, cachelines: 2, members: 19 */
/* sum members: 92, holes: 1, sum holes: 4 */
/* last cacheline: 32 bytes */
};
I don't think we can do much about the 4-byte hole as the members occupy
92 bytes only. I assume a single 4-byte hole shall be fine?
However, for cacheline aligment we can move the 3 top pointer-members,
`master_name`,`smmu` & `dev` which improves the cacheline aligment:
struct arm_smmu_event {
u8 id; /* 0 1 */
u8 class; /* 1 1 */
u16 stag; /* 2 2 */
u32 sid; /* 4 4 */
u32 ssid; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
u64 iova; /* 16 8 */
u64 ipa; /* 24 8 */
u64 raw[4]; /* 32 32 */
/* --- cacheline 1 boundary (64 bytes) --- */
bool stall; /* 64 1 */
bool ssid_valid; /* 65 1 */
bool privileged; /* 66 1 */
bool instruction; /* 67 1 */
bool s2; /* 68 1 */
bool read; /* 69 1 */
bool ttrnw; /* 70 1 */
bool ttrnw_valid; /* 71 1 */
const char * master_name; /* 72 8 */
struct arm_smmu_device * smmu; /* 80 8 */
struct device * dev; /* 88 8 */
/* size: 96, cachelines: 2, members: 19 */
/* sum members: 92, holes: 1, sum holes: 4 */
/* last cacheline: 32 bytes */
};
I'll fix this in the next version of the patch. Thanks!
>
> Will
Thanks,
Praan
next prev parent reply other threads:[~2024-10-24 17:02 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 18:00 [PATCH v4 0/3] iommu/arm-smmu-v3: Parse out event records Pranjal Shrivastava
2024-10-18 18:00 ` [PATCH v4 1/3] iommu/arm-smmu-v3: Introduce struct arm_smmu_event Pranjal Shrivastava
2024-10-19 1:56 ` Nicolin Chen
2024-10-21 6:20 ` Pranjal Shrivastava
2024-10-24 13:11 ` Will Deacon
2024-10-24 14:20 ` Pranjal Shrivastava
2024-10-24 17:02 ` Pranjal Shrivastava [this message]
2024-10-24 17:03 ` Jason Gunthorpe
2024-10-24 17:37 ` Pranjal Shrivastava
2024-10-28 12:23 ` Jason Gunthorpe
2024-10-28 14:46 ` Pranjal Shrivastava
2024-11-04 17:23 ` Daniel Mentz
2024-11-04 18:16 ` Pranjal Shrivastava
2024-11-04 18:19 ` Pranjal Shrivastava
2024-11-01 14:41 ` Robin Murphy
2024-11-01 15:08 ` Pranjal Shrivastava
2024-11-04 5:25 ` Daniel Mentz
2024-11-04 8:31 ` Pranjal Shrivastava
2024-11-07 0:10 ` Daniel Mentz
2024-11-07 14:33 ` Pranjal Shrivastava
2024-11-07 0:16 ` Daniel Mentz
2024-11-07 14:57 ` Pranjal Shrivastava
2024-11-11 22:20 ` Daniel Mentz
2024-11-12 0:52 ` Pranjal Shrivastava
2024-11-12 4:01 ` Daniel Mentz
2024-11-12 8:12 ` Pranjal Shrivastava
2024-10-18 18:00 ` [PATCH v4 2/3] iommu/arm-smmu-v3: Log better event records Pranjal Shrivastava
2024-10-19 2:06 ` Nicolin Chen
2024-10-19 4:51 ` Nicolin Chen
2024-10-21 6:29 ` Pranjal Shrivastava
2024-10-21 6:26 ` Pranjal Shrivastava
2024-10-21 22:53 ` Nicolin Chen
2024-10-24 13:15 ` Will Deacon
2024-10-24 14:14 ` Pranjal Shrivastava
2024-10-29 18:53 ` Will Deacon
2024-10-29 19:59 ` Pranjal Shrivastava
2024-10-24 19:00 ` Nicolin Chen
2024-10-29 18:49 ` Will Deacon
2024-11-01 15:05 ` Robin Murphy
2024-11-01 16:06 ` Pranjal Shrivastava
2024-11-04 6:36 ` Daniel Mentz
2024-11-04 10:51 ` Pranjal Shrivastava
2024-10-18 18:00 ` [PATCH v4 3/3] iommu/arm-smmu-v3: Avoid redundant master lookup in events Pranjal Shrivastava
2024-10-19 2:08 ` Nicolin Chen
2024-10-19 1:45 ` [PATCH v4 0/3] iommu/arm-smmu-v3: Parse out event records Nicolin Chen
2024-10-21 6:33 ` Pranjal Shrivastava
2024-10-21 22:51 ` Nicolin Chen
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=Zxp9kHerb-ln4ioO@google.com \
--to=praan@google.com \
--cc=danielmentz@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.