From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux1394-devel@lists.sourceforge.net
Cc: linux-scsi@vger.kernel.org
Subject: [PATCH] ieee1394: sbp2: remove unnecessary alignments of struct members
Date: Sun, 4 Feb 2007 13:04:32 +0100 (CET) [thread overview]
Message-ID: <tkrat.e82713a8340840b3@s5r6.in-berlin.de> (raw)
In-Reply-To: <tkrat.581ea0f6f3fe6292@s5r6.in-berlin.de>
The members "dma_addr_t command_orb_dma" and "dma_addr_t sge_dma" of
sbp2.h::sbp2_command_info do not have to be aligned themselves --- only
the memory which they point to has to be.
The member "struct sbp2_command_orb command_orb" has to be aligned on
4 bytes boundary which is guaranteed because it contains u32 members.
The member "struct sbp2_unrestricted_page_table scatter_gather_element",
i.e. the SBP-2 s/g table, has to be aligned on 8 bytes boundary
according to the SBP-2 spec. This is not a requirement for FireWire
controllers but could be expected by SBP-2 targets.
I see no need to align the members command_orb and
scatter_gather_element on CPU cacheline boundaries. It could have
performance benefits, but on the other hand sbp2 has a somewhat wasteful
allocation scheme which should be optimized first before further tweaks
like cacheline alignments. (E.g. don't always allocate SG_ALL s/g table
elements.)
Note, before as well as after the patch, the code relies on the
assumption that memory alignment in the virtual address space is
preserved in the physical address space after DMA mapping.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/ieee1394/sbp2.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.20-rc5/drivers/ieee1394/sbp2.h
===================================================================
--- linux-2.6.20-rc5.orig/drivers/ieee1394/sbp2.h
+++ linux-2.6.20-rc5/drivers/ieee1394/sbp2.h
@@ -250,15 +250,15 @@ enum sbp2_dma_types {
/* Per SCSI command */
struct sbp2_command_info {
struct list_head list;
- struct sbp2_command_orb command_orb ____cacheline_aligned;
- dma_addr_t command_orb_dma ____cacheline_aligned;
+ struct sbp2_command_orb command_orb;
+ dma_addr_t command_orb_dma;
struct scsi_cmnd *Current_SCpnt;
void (*Current_done)(struct scsi_cmnd *);
/* Also need s/g structure for each sbp2 command */
struct sbp2_unrestricted_page_table
- scatter_gather_element[SG_ALL] ____cacheline_aligned;
- dma_addr_t sge_dma ____cacheline_aligned;
+ scatter_gather_element[SG_ALL] __attribute__((aligned(8)));
+ dma_addr_t sge_dma;
void *sge_buffer;
dma_addr_t cmd_dma;
enum sbp2_dma_types dma_type;
--
Stefan Richter
-=====-=-=== --=- --=--
http://arcgraph.de/sr/
next prev parent reply other threads:[~2007-02-04 12:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-14 18:45 [PATCH] ieee1394: sbp2: lower block queue alignment requirement Stefan Richter
2007-01-14 19:19 ` James Bottomley
2007-01-14 20:14 ` Stefan Richter
2007-01-15 19:39 ` Kristian Høgsberg
2007-01-15 19:50 ` Mike Christie
2007-01-15 20:02 ` Stefan Richter
2007-01-15 21:24 ` James Bottomley
2007-01-25 21:35 ` Stefan Richter
2007-02-04 12:04 ` Stefan Richter [this message]
2007-02-04 12:05 ` [PATCH] ieee1394: sbp2: enforce 32bit DMA mapping Stefan Richter
2007-02-04 16:06 ` David Moore
2007-02-04 19:25 ` Stefan Richter
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=tkrat.e82713a8340840b3@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-scsi@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox