Re: Memory alignment of pointers for sparc64

[Bill Moseley <moseley@hank.org>]

At 10:57 AM 09/05/02 -0600, Jason Gunthorpe wrote:
>AFAIK on 32 bit SPARC, like you are using (and on other platforms, like
>MIPS, etc) you often need to align structures on 8 bytes for floating
>point members. doubles have to be aligned on their size generally.

Ok, so it's based on the data you are storing not how many bytes it takes
to store a pointer.

>If your structures contains only things <= 32 bits then you can get away
>with a 4 byte alignment in general, but if you add a double or a long long
>then some arches will demand 8 bytes.

Which is what is happening, so it seems.  And the problem is automatically
detecting which systems need the 8 bytes.

Here's where it's blowing up:

    struct dev_ino *p;
    struct stat buf;
    ...
    // allocate a bit of memory from the pool.
    p = (struct dev_ino *) Mem_ZoneAlloc(
            sw->Index->entryZone,sizeof(struct dev_ino));

    p->dev = buf.st_dev;  // *poof!*  SIGBUS

SIGBUS when the address ends in 4 or C but OK when it ends in 0 or 8.

>Generally an allocator of this nature should align to the largest
>intrinsic type used in the structures it is allocating for. If that's a
>double or a uint64_t then it has to be 8 bytes.

And for a general purpose allocator it should be 8 bytes.

I just ran a test of Swish-e indexing 200,000 documents using an alignment
of 4 bytes and of 8 bytes.  This was on Debian testing/i386 Athlon XP 1800+
with 1/2G and no load.

4 byte alignment:
278MB RSS
200000 files indexed.  392947710 total bytes.  40623746 total words.
Elapsed time: 00:07:32 CPU time: 00:05:34

8 byte alignment:
312MB RSS
200000 files indexed.  392949861 total bytes.  40627145 total words.
Elapsed time: 00:08:04 CPU time: 00:06:01

Maybe that difference is not worth worrying about. 

Thanks for your time.


-- 
Bill Moseley
mailto:moseley@hank.org