xfs
[Top] [All Lists]

Re: [PATCH 3/3] xfs: remove __arch_pack

To: Christoph Hellwig <hch@xxxxxx>
Subject: Re: [PATCH 3/3] xfs: remove __arch_pack
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 20 Jul 2016 09:46:34 +1000
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160719085208.GA21785@xxxxxx>
References: <1466754767-10657-1-git-send-email-hch@xxxxxx> <1466754767-10657-4-git-send-email-hch@xxxxxx> <478743f8-774f-d363-2e3e-40cd0963d8a1@xxxxxxxxxxx> <20160718053746.GA16044@dastard> <20160719085208.GA21785@xxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Jul 19, 2016 at 10:52:08AM +0200, Christoph Hellwig wrote:
> 
> 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.

OK, that's probably good enough to go with for now. Thanks for
following up, Christoph.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>