On Wed, Dec 09, 2009 at 12:29:40PM +0100, Jan Kara wrote:
> On Tue 08-12-09 23:54:24, tytso@xxxxxxx wrote:
> > Here's a revised version of your patch that I've included in the ext4
> > patch queue. I've removed the use of the atomic_t data type. I've
> OK, I'm just unsure: Isn't even 32-bit read non-atomic if it is not
> properly aligned e.g. on powerPC? So shouldn't we make sure those inode
> fields are aligned to 32-bit boundary (or at least add a comment about
> that)?
But gcc guarantees such alignments, unless you do something horrible
from a performance point of view, such as using
__attribute__((packed)). And in fact, if things are not aligned, on
some platforms unaligned access will trigger a software trap, and the
kernel trap handler has to fix up the unaligned access. (I believe
Power is one of these platforms if memory serves correctly.) Even on
platforms that don't, the performance hit where the hardware has to do
the unaligned access so horrible that gcc avoids the misalignment
automatically.
That's why sometimes I'll go around and try to adjust structure member
orders, since something like this:
struct foo {
short int a;
int b;
short int c;
} foo_array[2];
Will consume 24 bytes.... while this:
struct foo {
short int a;
short int c;
int b;
} foo_array[2];
... will consume 16 bytes. For structures that are used in huge
amounts (like inode slab caches), it can mean a measurable memory
savings.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
