[Pw_forum] Maximing amount of memory available under Linux/x86

[Serguei Patchkovskii]

Hi folks,

Since the last time the question on maximizing the amount of
RAM available for dynamic allocation on Linux/x86 systems came
up, I had a chance to revisit the issue. As it turns out,
recent Linux kernels provide a very convenient way of fiddling
with some of the kernel parameters, which required a kernel
rebuild before. As of 2.4.21 kernels, TASK_UNMAPPED_BASE can
be adjusted on a per-process basis. So, now programs which
need to maximize the amount of ALLOCATE'able memory can get
it, even with stock kernels.

The needed adjustment (to /proc/self/mapped_base) can only
be done by euid=0 process. To get it in a normal user process,
the it has to be invoked with a small wrapper (attached),
which MUST BE SET-UID ROOT.

Here is what I get on a stock Suse 9.0 kernel:

	ps at e05-01:~/snippets> ./bigmem
	 BSS is around    807DD58 (   128.492 Mb)
	 stack is around   BFFFF4B8 ( -1024.003 Mb)
	 Max array size =   2036.000 mbyte
	 Last array was at     409BD040 (  1033.738 Mb)
	 Max second array size =      0.000 mbyte
	 Last second array was at     409BD040 (  1033.738 Mb)
	ps at e05-01:~/snippets> maxram ./bigmem
	 BSS is around    807DD58 (   128.492 Mb)
	 stack is around   BFFFF4D8 ( -1024.003 Mb)
	 Max array size =   2044.000 mbyte
	 Last array was at     109BC040 (   265.734 Mb)
	 Max second array size =    760.000 mbyte
	 Last second array was at     905BD040 ( -1786.262 Mb)
	ps at e05-01:~/snippets> uname -a
	Linux e05-01 2.4.21-199-smp4G #1 SMP ...

Enjoy!

Serguei

---
Dr. Serguei Patchkovskii

Tel: +1-(613)-990-0945
Fax: +1-(613)-947-2838
E-mail: Serguei.Patchkovskii at nrc.ca

Coordinator of Modelling Software
Theory and Computation Group
Steacie Institute for Molecular Sciences
National Research Council Canada
Room 2011, 100 Sussex Drive
Ottawa, Ontario
K1A 0R6 Canada
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: maxram.c
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20040512/4163cf42/attachment.c>