From: Christoph Hellwig <hch@lst.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: [PATCH 3/3] xfs: remove __arch_pack
Date: Tue, 19 Jul 2016 10:52:08 +0200 [thread overview]
Message-ID: <20160719085208.GA21785@lst.de> (raw)
In-Reply-To: <20160718053746.GA16044@dastard>
On Mon, Jul 18, 2016 at 03:37:46PM +1000, Dave Chinner wrote:
> > The reason I did this in the first place was a vague notion that unconditional
> > packing was harmful.
> >
> > http://digitalvampire.org/blog/index.php/2006/07/31/why-you-shouldnt-use-__attribute__packed/
> >
> > "However, it's actively harmful to add the attribute to a structure that's
> > already going to be laid out with no padding."
> > ...
> > "gcc gets scared about unaligned accesses and generates six times as much code
> > (96 bytes vs. 16 bytes)! sparc64 goes similarly crazy, bloating from 12 bytes
> > to 52 bytes"
> >
> > I don't know if that's (still) correct or not, but that was the reason
> > for the selective __pack application way back when. Might be worth
> > investigating?
>
> Christoph? The first two ptches are fine, but more info is needed
> for this one...
I don't have a sparc64 compiler to test unfortunately. But I can confirm
that on x86-64 xfs.o is bit to bit identical with or without the patch.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-07-19 8:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 7:52 get rid of unaligned embedded structs in on-disk structures Christoph Hellwig
2016-06-24 7:52 ` [PATCH 1/3] xfs: kill xfs_dir2_sf_off_t Christoph Hellwig
2016-06-24 7:52 ` [PATCH 2/3] xfs: kill xfs_dir2_inou_t Christoph Hellwig
2016-06-24 7:52 ` [PATCH 3/3] xfs: remove __arch_pack Christoph Hellwig
2016-06-24 14:55 ` Eric Sandeen
2016-07-18 5:37 ` Dave Chinner
2016-07-19 8:52 ` Christoph Hellwig [this message]
2016-07-19 23:46 ` Dave Chinner
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=20160719085208.GA21785@lst.de \
--to=hch@lst.de \
--cc=david@fromorbit.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/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