Greetings! As I mentioned, I'm not sure this (Linux big memory) configuration option does what we'd like, which is effectively to move the starting address at which shared libraries are loaded. By default on 32bit Linux, this is at 1Gb (0x40000000), which prevents a contiguous memory image greater than this value. It is (rather) well known that 32bit x86 Linux can be made to support up to a 2.7Gb contiguous user memory image. This is used, for example, in running oracle and db2 on large servers. There are several methodologies I've run across, some of them dated. Red Hat used to supply a patch which provided a 'mapped_base' pseudo-file under /proc/self to which setuid programs could write their own requested starting address for shared libraries. It appears that they have obsoleted this mechanism in favor of a default strategy of having all mmapped allocations (such as shared libraries, malloc'ed memory, etc) count down from the bottom of the stack, and memory added via sbrk counting up from the end of the executable's .data segment, providing thereby one undivided user dynamic memory region. Lastly, there may be some facility to move the shared library loading address with prelink outside of the kernel, but I have not discovered it yet.
Would you perhaps know how to configure a kernel at your site to follow the oracle server examples documented at various places on the net? Warren and Bob -- I have a modified twc (two word cons) build now with the following, pending one little bug I'm chasing: 1) Lower the heap start to 0 or as close as possible 2) big random numbers via gmp 3) configurable immediate fixnum table in inaccesible regions of memory, e.g. most likely above the C stack, which is never movable to my understanding. (On 32bit Linux, this gives 512M immediate fixnums at 0xc0000000.) The user will be able to control this via the configure script. I'll probably report it in (room) too, together with heap start and any shared memory ceiling detected. I believe this is portable in principle. I'm about ready to commit this into CVS head (2.7.0). If you have any indication on whether you are seeing net space savings (given that the other types are padded) and if so what magnitude, that would be helpful. At this point, I could provide a configuration optiom toggling the two word cons, but I don't really see any disadvantages in making it the default. The small speed discrepancy you reported is, I believe, due to the stack alignment and stack wiping code I put in to avoid holding on to your large lists. This can be verified at some later point. One last note on the space usage -- we should see two ancillary gains, confirmation of which would be great. One is that fixnums are now the same size as cons, and therefore should not compete with them in the optimize-maximum-pages expansion algorithm, as in your gulp example. Not that the old behavior was acceptable -- more on this later. Secondly, of course, immediate fixnums take no space at all. We will have to wait a bit to confirm this in your specific applications. Take care, Robert Boyer <[EMAIL PROTECTED]> writes: > From: Kay Nettle <[EMAIL PROTECTED]> > Subject: Re: Linux configuration help > To: Robert Boyer <[EMAIL PROTECTED]> > Date: Tue, 31 May 2005 11:22:25 -0500 > > You're welcome. If he has any questions he can email me directly. > > Kay > ---------- > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel