[prev in list] [next in list] [prev in thread] [next in thread] 

List:       beowulf
Subject:    RE: [Beowulf] NASTRAN on cluster
From:       "Lombard, David N" <david.n.lombard () intel ! com>
Date:       2005-04-12 22:12:35
Message-ID: 187D3A7CAB42A54DB61F1D05F012572205D6B2BE () orsmsx402 ! amr ! corp ! intel ! com
[Download RAW message or body]

From: Mark Hahn of Tuesday, April 12, 2005 2:37 PM
> To: beowulf@beowulf.org
> Subject: RE: [Beowulf] NASTRAN on cluster
> 
> > > > > easy to change, though, at least to give 2-2.5 GB on ia32.
> > > > 
> > > > It may *not* be easy to change, depending on the distro and glibc.
> > > 
> > > It *is* relatively easy to change. In fact in 2.4 kernels the
> > > TASK_UNMAPPED_BASE (TUB) is not fixed but at 1/3 of TASK_SIZE which
is
> > > available physical memory - 1G (for the kernel)=3G by default. This
is
> > > set in <line-2.4.xx>/include/asm-i386/processor.h. You can change
that
> > > relatively safely to 1/12 which will let you allocate closer to ~3G
> > > using mmap.
> > 
> > It is easy to change.  I developed a simple hack for this back in
2001,
> > and a much better per-process patch was developed later.  MSC.Nastran
> 
> this solution has been known for longer than that - at last back
> to 1998-ish on LKML.

I only claimed to have solved the problem as needed by Nastran in my
primitive way, and then found a perfect problem for the more general
solution later offered elsewhere--I'm fairly the person that developed
the better solution ever heard or cared about Nastran.  Most people
don't :-)

> > was introduced by some distros, including RHL and derivatives, that
had
> > the effect of pinning glibc to a specific address.  The net was that
> 
> this is "prelinking", no?  I have the impression that you can pretty
> easily control which binaries are prelinked, and even reverse the
change.

Yes, prelinking.  Thanks; as I mentioned, I forgot specifics.

> > > Most "legacy" Fortran codes (including the one we sell)
> > > allocate memory in one large chunk, so your compiler or glibc resp.
> > > will use mmap to allocate and hence you are stuck with 2G.
> > 
> > Subject to the above discussion.
> 
> interestingly, you can also avoid mmap entirely if you statically link.

Which is not an option for ISV codes...

-- 
David N. Lombard
 
My comments represent my opinions, not those of Intel Corporation.

_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit \
http://www.beowulf.org/mailman/listinfo/beowulf


[prev in list] [next in list] [prev in thread] [next in thread]