[Beowulf] NASTRAN on cluster

[Lombard, David N]

From: Mark Hahn of Tuesday, April 12, 2005 2:37 PM
>To: beowulf at 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.