Re: Memory alignment of pointers for sparc64
If I understand correctly, how about `__alignof__', utilizing GCC's
knowledge of the architecture?
$ cat a.c
#include
#ifdef __GNUC__
size_t alignment = __alignof__ (double);
#else
size_t alignment = 8;
#endif
main () { printf ("%d\n", alignment); exit (0); }
$ arch && cc a.c && ./a.out
i586
4
---
$ arch && cc a.c && ./a.out
sparc64
8
Re: Memory alignment of pointers for sparc64
At 02:16 PM 09/05/02 -0600, Jason Gunthorpe wrote:
>
>On Thu, 5 Sep 2002, Bill Moseley wrote:
>
>>
>> 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.
>
>Hum, that seems a bit surprising, what does your 'struct dev_ino' look
>like?
struct dev_ino
{
dev_t dev;
ino_t ino;
struct dev_ino *next;
};
And now I see another SIGBUS with this code:
Program received signal SIGBUS, Bus error.
0x0001ae60 in coalesce_word_locations (sw=0xdbdf0, indexf=0xf46e8,
e=0x7037dd50) at index.c:2691
2691*(unsigned int *)size_p = tmp;
And if I print out the address:
tmp is an unsigned int.
size_p at: 9BB5D
Bus error.
My guess is that's another alignment error.
That bit of code is used to compress our data in RAM.
Thanks,
--
Bill Moseley
mailto:[EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
On Thu, 5 Sep 2002, Bill Moseley wrote: > > 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. Hum, that seems a bit surprising, what does your 'struct dev_ino' look like? Jason
Re: Memory alignment of pointers for sparc64
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 20 files indexed. 392947710 total bytes. 40623746 total words. Elapsed time: 00:07:32 CPU time: 00:05:34 8 byte alignment: 312MB RSS 20 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:[EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
On Thu, 5 Sep 2002, Bill Moseley wrote: > About all I understand of this problem is that our code allocates memory > on 4-byte boundaries, and that cased SIGBUS on this one machine. I > printed out the results of malloc() calls and noticed it was always on > 8-byte boundaries. Hard-coding to 8-byte fixed our code. 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. 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. The basic rule is that the member of a structure has to be aligned on it's size - so a 2 byte short needs to have an addresss congruent to 2, a 4 byte long needs to be congruent to 4, a double to 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. Jason
Re: Memory alignment of pointers for sparc64
At 09:17 AM 09/05/02 -0400, Michael J. Saletnik wrote: >On September 4, 2002 at 23:06, Bill Moseley wrote: > > the allocated pointers based on the sizeof(void *). > >On September 5, 2002 at 08:13, Ben Collins wrote: > > What was wrong with the original usage of sizeof(long)? > >Wouldn't it be most "correct" to use sizeof(caddr_t) ? I'm not familiar with caddr_t. (And I don't really have a grasp of what the underlying issue is regarding memory alignment.) Still, caddr_t == 4 on this machine (where I need 8), so it can't be used in all cases. Thanks, -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
On Thu, 5 Sep 2002, Ben Collins wrote: > On Wed, Sep 04, 2002 at 11:06:04PM -0700, Bill Moseley wrote: > > I'm pretty sure you mean sparc and not sparc64 (even if you are running > an ultra, it is still 32bit userspace). On sparc64, sizeof(void *) does > in fact equal 8bytes (64bit bins). Well, my knowledge of this stuff is poor. On the sourceforge machine: http://sourceforge.net/docman/display_doc.php?docid=10472&group_id=1#usf-cf-sparc-linux-1 It's returning sizeof(void *) == 4. About all I understand of this problem is that our code allocates memory on 4-byte boundaries, and that cased SIGBUS on this one machine. I printed out the results of malloc() calls and noticed it was always on 8-byte boundaries. Hard-coding to 8-byte fixed our code. >From the debian page I read that this runs 64 bit kernel and 32 bit user space, so then I assumed (the important word here ;) ) the 8-byte allocations were a hardware requirement. > Why not force minimum 8byte allocations? Will it really cause that much > of a usage problem? Would probably cause less fragmentation, I bet. The point of this code is to allocate a lot of very small chunks of memory that are not released. Fragmentation is not an issue since the memmory is not freed. > Guess you could do: > > #ifdef __sparc__ > # define PointerAlign 8 > #else > # define PointerAlign sizeof(void *) > #endif That's what I was doing, but didn't want to use up space when it wasn't necessary, since the point of the code was to reduce wasted memory. > What was wrong with the original usage of sizeof(long)? Good question. That's my ignorance. I assumed it was an addressing issue -- that the SIGBUS was due to addressing incorrectly. Is is really an issue of trying to write a long into a location? If so, then I suspect I should be using sizeof(long). I'll look at obstack, but in the mean time it seems like I have four options: 1) set for 8 bytes on all __sparc__ machines. that will waste a little extra memory for each small call. 2) keep trying to find a defined() value that I could check (how does malloc() know that it needs to be 8-byte aligned?) 3) find some autoconf macro that somehow checks this and sets a define. 4) allow a ./configure option to set some define -- (hey, the point of autoconf is to be "auto") Number two seems to the be best option, but I'm not sure how portable that is. Perhaps option four is the easiest. I'll also run some tests with setting it to 8 bytes and see just how much more RAM gets used. Thanks very much for the help, Ben. -- Bill Moseley [EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
On September 4, 2002 at 23:06, Bill Moseley wrote:
> the allocated pointers based on the sizeof(void *).
On September 5, 2002 at 08:13, Ben Collins wrote:
> What was wrong with the original usage of sizeof(long)?
Wouldn't it be most "correct" to use sizeof(caddr_t) ?
--
{michael}
Re: Memory alignment of pointers for sparc64
> Swish-e allocates memory from a memory pool. The application byte-aligns > the allocated pointers based on the sizeof(void *). (Actually the original Oh, one other thing you may want to look at is obstack. Glibc contains the functions internally, but you can also grab obstack.[ch] from the glibc source (it is very portable, and generic). Basically does what you are trying to do (allocations from single or multiple pools). Obstack does use sizeof(long) for this alignment case, FYI, and since dpkg uses it, I know it works on every arch that debian supports (alpha, ia64, hppa, mips, mipsel, sparc, etc.) -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Memory alignment of pointers for sparc64
On Wed, Sep 04, 2002 at 11:06:04PM -0700, Bill Moseley wrote: > Hi, > > I was trying to build the C application swish-e on the Sourceforge Sun > Ultra60 - Debian 3.0. > > Swish-e allocates memory from a memory pool. The application byte-aligns > the allocated pointers based on the sizeof(void *). (Actually the original > programmer used sizeof(long) ). So on 4 byte machines you would get > pointers that end in 0, 4, 8, and C hex. On DEC alpha sizeof(void *) == 8 > so the pointers low byte is 0 and 8. > > Now the problem is that on sparc64 sizeof(void *) == 4 but we need to align > our pointers on 8-byte boundaries otherwise we get SIGBUS errors. I'm pretty sure you mean sparc and not sparc64 (even if you are running an ultra, it is still 32bit userspace). On sparc64, sizeof(void *) does in fact equal 8bytes (64bit bins). Why not force minimum 8byte allocations? Will it really cause that much of a usage problem? Would probably cause less fragmentation, I bet. Guess you could do: #ifdef __sparc__ # define PointerAlign 8 #else # define PointerAlign sizeof(void *) #endif What was wrong with the original usage of sizeof(long)? -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
