[Beowulf] NASTRAN on cluster
Lombard, David N
david.n.lombard at intel.com
Tue Apr 12 15:12:35 PDT 2005
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
>> >available physical memory - 1G (for the kernel)=3G by default. This
>> >set in <line-2.4.xx>/include/asm-i386/processor.h. You can change
>> >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
>> 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
>> was introduced by some distros, including RHL and derivatives, that
>> 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
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.
More information about the Beowulf