All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.