Re: Why is it called sparc64?
At 05:10 PM 09/07/02 -0700, James Fowler wrote: >IIRC it is because all of the SPARCs prior to the ULTRA line >were 32bit. The UltraSPARCs and beyond were 64 bit machines. Thus an ULTRA >10 has both a machine name and a sparc64 designation. Ah, ok. You probably saw my question earlier this week about this machine. I had posted to the solaris list first to find out more about the machine, which I know nothing about. (I now realize that this list was the place to ask my problem.) One of the posts said: "If you're on an Ultra 60, you're not using a SPARC64 - that was a 64-bit SPARC chip made by HaL (later bought out by Fujistu). I assume you really mean "an UltraSparc running in 64-bit mode." So that made me wonder why it was called a sparc64. Anyway, if curious you can see the thread at: http://groups.google.com/groups?dq=&hl=xx-elmer&lr=&ie=UTF-8&oe=utf-8&frame=right&th=7a22f4c0e87d112c&seekm=43125ccc.0209041413.13c8f31a%40posting.google.com#link2 With a little linux bashing at the end ;) Thanks, -- Bill Moseley mailto:[EMAIL PROTECTED]
Why is it called sparc64?
BTW -- The Ultra 10 on sourceforge say: $ uname -a Linux usf-cf-sparc-linux-1 2.4.18 #2 Thu Apr 11 14:37:17 EDT 2002 sparc64 unknown I gather from the Solaris list it's a SPARC v9, and a sparc64 is something else. -- Bill Moseley mailto:[EMAIL PROTECTED]
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
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
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]
Memory alignment of pointers for sparc64
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. So, can anyone suggest a way in C to test for this? Something like #if defined(__sparc64__) # define PointerAlign 8 #else # define PointerAlign sizeof( void * ) #endif My C skills are not great, and I know much less about porting. So it would be great to find a reasonably potable way to set the align size -- any suggestions are more than welcome. Thanks. -- Bill Moseley mailto:[EMAIL PROTECTED]
