Re: [Dpcl-develop] ASC_insufficient_memory error

[Dave W. <dwo...@us...>]

Steve
MAGIC_HEADER_PATTERN looks ok. This is just an integer that is used as a 
marker for determining shared memory is already initialized

BITS_IN_A_WORD looks ok. The shared memory allocation code keeps track of 
4096-byte memory pages with a  bitmap, 1 bit per 4096 byte page. This 
constant is used in the calculation to determine the size of the bitmap 
array needed to hold 65536 (64K) 4096 byte pages, which covers 256MB of 
shared memory. It is also used in filling in the bitmap array when pages 
are allocated. The bitmap is defined as an array of unisgned in, so the 
value 32 is correct.

FULL_ONE_MASK also looks correct. This is used in the loop marking shared 
memory pages allocated. The loop marks 32 shared memory bitmap entries as 
allocated at one time. There is code following the loop to handle the 
leftover pages which are not a multiple of 32 pages.

WORD_WITH_LEFMOST_BIT_ON looks correct. This is used in a calculation 
defining which bit to look at in an unsigned int when determining shared 
memory allocations

Now that we are trying to debug shared memory code, I remember a  problem 
with shared memory allocation with the ia32 linux implementation when we 
first did the port. On AIX, we can get access to a 256MB shared memory 
segment except in cases where the application uses large amounts of memory 
for things like the heap (malloc'ed memory) segment. On ia32 linux, the 
default shared memory allocation limit was 16MB, at least on the system we 
were using for the port. We fixed the code allocating the shared memory, 
but apparently did not address the smaller allocation here. I doubt this 
has anything to do with your problem, but it might be worth investigating. 
If possible, I would like you to try setting the limit to 256MB

I believe you can check the system shared memory allocation limit by 
issuing 'cat /proc/sys/kernel/shmmax' which will display a single number. 
I also believe you can set this limit by issuing (as root) the command 
'echo nnn > /proc/sys/kernel/shmmax' where nnn is the number of bytes max 
allocation. For 256MB use 268435456. Whatever you set will be the new 
limit until changed again or the system is rebooted.

If I get a chance to look at code tomorrow, I will see if I can find the 
code where we originally fixed this and see what possible problems exist 
by assuming 256MB shared memory exists.

Dave





sl...@sg...
Sent by: dpc...@ww...
12/08/2003 02:58 PM
 
        To:     dpc...@ww...
        cc:     sl...@sg...
        Subject:        [Dpcl-develop] ASC_insufficient_memory error



  Tried DaveW's suggestion re: XoredPtrs and this did not move my problem. 
I will
 definitely put it on my running list of 64-bit considerations though. 
Looking
 thru some #defines in ~dpcl/src/daemon_RT/include/os/linux/ShmManager.h I 
see
 a number of 32-bit problems, to wit:

#define MAGIC_HEADER_PATTERN 0x88888888
#define BITS_IN_A_WORD 32
#define FULL_ONE_MASK 0xffffffff
#define WORD_WITH_LEFMOST_BIT_ON 0x80000000

  Are these actually used or they also innocuous like some of my earlier
 reported suspects??

                                         Thanks again to DaveW - SteveC
                                                                 SGI 
Compilers/Tools
_______________________________________________
Dpcl-develop mailing list
Dpc...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-develop