[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: address@hidden: Re: Linux configuration help]

From: Camm Maguire
Subject: [Gcl-devel] Re: address@hidden: Re: Linux configuration help]
Date: 31 May 2005 18:58:22 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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

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 <address@hidden> writes:

> From: Kay Nettle <address@hidden>
> Subject: Re: Linux configuration help 
> To: Robert Boyer <address@hidden>
> 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                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]