[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] --patch46
Re: [Axiom-developer] --patch46
01 Nov 2005 11:47:14 -0500
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
"Bill Page" <address@hidden> writes:
> On October 31, 2005 9:31 AM you wrote:
> > Greetings! And please excuse me -- this thread has slipped under
> > the radar here.
> No problem.
> > Bill, here is the problem -- Redhat 9 is apparently placing the
> > stack within the first 1Gb of memory, but you are requesting this
> > amount for your heap. GCL won't (or tries not to) allow the head
> > to overrun the stack:
> > ...
> > In all of the machines I've looked at, this is about the worst
> > stack placement I've seen. Is this 'enterprise' or 'normal'?
> Actually, I don't know very much about this server. It is a
> "Unmanaged Virtual Servers (VPS/VDS)" hosted at a commercial
> ISP called RoseHosting. (This is the system which runs MathAction
> and for which Tim Daly is still paying the full operational
> costs.) http://www.rosehosting.com
> Can you deduce anything from the following system information:
> # uname -a
> Linux axiom-developer.org 184.108.40.206-RH1956 #9 SMP
> Fri May 20 20:48:44 CDT 2005 i686 i686 i386 GNU/Linux
This is a recent kernel. The stack placement is probably a kernel
configuration option (I hope -- we still run 2.4).
> I think that what we have is a legacy RedHat 9 configuration.
> According to the RoseHosting website, we could probably upgrade
> to a Fedora Core 4 configuration.
> Perhaps if I contacted the admins at RoseHosting, I might be
> able to get more details.
> > I thought the former had a sophisticated mechanism to push
> > the stack and the shared memory area as high up in memory
> > as possible.
> > I know of no way to change this short of getting a different
> > Linux kernel, where the issue should be addressable.
> I think the above info suggests we are running 220.127.116.11.
> That's fairly new isn't it?
> > One thing we could do is relax the power of two constraint
> > on maxpages if a lesser amount would suffice.
> Yes, very likely a lesser amount would suffice.
OK, will look into this and consider putting into 2.6.8pre.
> > You say there is another work around with
> > si::allocate-contiguous-pages, which I suspect to be a
> > feather-edge manipulation issue, but am not sure. You
> > can check this out by doing (room) after your job has
> > completed and seeing how close you are to OOM.
> Ok. Here is the output of (room) in the case of setting
> si::allocate-contiguous-pages, see:
> )lisp (room)
> 1528/1528 59.3% 4 CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
> 94/200 99.9% FIXNUM SHORT-FLOAT CHARACTER
> RANDOM-STATE READTABLE SPICE
> 340/500 75.9% SYMBOL STREAM
> 1/8 23.1% PACKAGE
> 65/400 99.0% ARRAY HASH-TABLE VECTOR BIT-VECTOR
> PATHNAME CCLOSURE CLOSURE
> 500/500 53.3% 1 STRING
> 195/331 99.8% 2 CFUN BIGNUM
> 40/115 97.6% SFUN GFUN VFUN AFUN CFDATA
> 3000/3000 2 contiguous (237 blocks)
> 1476 hole
> 1000 73.5% 1 relocatable
> 2763 pages for cells
> 8239 total pages
> 116036 pages available
> 6797 pages in heap but not gc'd + pages needed for
> gc marking
> 131072 maximum pages
> Value = NIL
You have plenty of room here. Is this before or after running the job
which required the allocate-contiguous-pages?
> >From this output how can I tell how "close I am to OOM"? Maybe
> the FIXNUM ... memory is a problem? What can I do about that?
> > In addition to the contiguous page function you've found, here
> > are some other ways to explicitly allocate memory to various
> > types:
> > (si::allocate 'cons 400)
> > (si::allocate-relocatable-pages 10000)
> > <will explain the allocate sgc functions later if desired>
> How can I related these to the output of (room)?
"pages available" tells you about proximity to OOM. The two functions
mentioned above, in addition to si::allocate-contiguous-pages, alter
the denominator of the corresponding type output by room. I.e. it
will allow allocation up to this amount without trying to clear space
with a gc.
> > The typed pages are self-explanatory I'd think. Contiguous
> > pages are used for untyped memory which cannot be moved,
> > typically compiled-code. relocatable-pages hold untyped
> > memory to which no pointer refers directly (i.e. outside of
> > a lisp object, where we can control the reference in the
> > garbage collector), string bodies, bignum bodies, certain
> > arrays, etc.
> Where do FIXNUM ... things live?
In 2.6, fixnums, short-floats, and long-floats all reside in unmovable
locations in correspondingly typed pages on the heap. There is a
small fixnum table outside the heap in the text function of the
executable. In 2.7, most fixnums are immediate fixnums consuming no
memory but overlaying the memory range reserved by the kernel.
> > Here is a bit of clarification on the room report:
> > 211/211 42.9% CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
> > ^ pages allocated for this type
> > ^ maximum pages before triggering GC
> > ^ Percent of the allocated pages holding live
> > objects
> > =============================================================
> > >(room)(si::allocate 'cons 400)(room)
> > 211/211 42.9% CONS RATIO LONG-FLOAT COMPLEX
> > STRUCTURE
> > 2/28 40.8% FIXNUM SHORT-FLOAT CHARACTER
> > RANDOM-STATE READTABLE SPICE
> > 47/49 72.9% SYMBOL STREAM
> > 1/2 12.8% PACKAGE
> > 1/38 56.8% ARRAY HASH-TABLE VECTOR
> > BIT-VECTOR PATHNAME CCLOSURE
> > CLOSURE
> > 16/32 85.8% STRING
> > 3/27 98.3% CFUN BIGNUM
> > 6/115 88.1% SFUN GFUN VFUN AFUN CFDATA
> > 347/512 contiguous (86 blocks)
> > 13107 hole
> > 5242 0.0% relocatable
> > 287 pages for cells
> > 18983 total pages
> > 101769 pages available
> > 10320 pages in heap but not gc'd + pages needed for gc marking
> > 131072 maximum pages
> Thanks for the help.
> Bill Page.
> Axiom-developer mailing list
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- Re: [Axiom-developer] --patch46,
Camm Maguire <=