<?xml version="1.0"?>
<!DOCTYPE flagsdescription SYSTEM
       "http://www.spec.org/dtd/cpuflags1.dtd">

<!-- This file defines platform settings -->
<flagsdescription>

<filename>amd-platform-amd909gh</filename>

<title>AMD Platform settings file</title>

<!-- Platform Settings -->
<platform_settings>
<![CDATA[
<p><b>Linux Huge Page settings</b></p>
<p>In order to take full advantage of using PGI's huge page runtime library, your system must be configured to use huge pages.
It is safe to run binaries compiled with "-Msmartalloc=huge" on systems not configured to use huge pages, however, you will not
benefit from the performance improvements huge pages offer.  To configure your system for huge pages perform the following steps:
</p>
<ul>
      <li>Create a mount point for the huge pages: "mkdir /mnt/hugepages"</li>
      <li>The huge page file system needs to be mounted when the systems reboots.  Add the following to a system boot configuration file before any services are started: "mount -t hugetlbfs nodev /mnt/hugepages"</li>
      <li>Set vm/nr_hugepages=N in your /etc/sysctl.conf file where N is the maximum number of pages the system may allocate.</li>
      <li>Reboot to have the changes take effect.</li>
</ul>
<p>Note that further information about huge pages may be found in your Linux documentation file: /usr/src/linux/Documentation/vm/hugetlbpage.txt</p>
<p><b>PGI_HUGE_PAGES</b></p>
<p>The maximum number of huge pages an application is allowed to use can be set at run time via the environment variable PGI_HUGE_PAGES.  If not set, then the process may use all available huge pages when compiled with "-Msmartalloc=huge" or a maximum of <b>n</b> pages where the value of <b>n</b> is set via the compile time flag "-Msmartalloc=huge:<b>n</b>.</p>
<p><b>Using numactl to bind processes and memory to cores</b></p>
<p>For multi-copy runs or single copy runs on systems with multiple sockets, it is advantageous to bind a process to a particular core.  Otherwise, the OS may arbitrarily move your process from one core to another.  This can effect performance.  To help, SPEC allows the use of a "submit" command where users can specify a utility to use to bind processes.  We have found the utility 'numactl' to be the best choice.</p>
<p>numactl runs processes with a specific NUMA scheduling or memory placement policy.  The policy is set for a command and inherited by all of its children.  The numactl flag "--physcpubind" specifies which core(s) to bind the process. "-l" instructs numactl to keep a process memory on the local node while "-m" specifies which node(s) to place a process memory.  For full details on using numactl, please refer to your Linux documentation, 'man numactl'</p>
<p>Note that some versions of numactl, particularly the version found on SLES 10, we have found that the utility incorrectly interprets application arguments as it's own.  For example, with the command "numactl --physcpubind=0 -l a.out -m a", numactl will interpret a.out's "-m" option as it's own "-m" option.  To work around this problem, a user can put the command to be run in a shell script and then run the shell script using numactl.  For example: "echo 'a.out -m a' > run.sh ; numactl --physcpubind=0 bash run.sh"</p>
<p><b> ulimit -s &lt;n&gt;</b></p>
<p>
           Sets the stack size to <b>n</b> kbytes, or <b>unlimited</b> to allow the stack size
           to grow without limit. 
</p>
<p><b> ulimit -l &lt;n&gt;</b></p>
<p>
           Sets the maximum size of memory that may be locked into physical memory.
</p>
</p>
<p><b>NCPUS</b></p>
<p>
           Sets the maximum number of OpenMP parallel threads auto-parallelized (-Mconcur) applications may use.
</p>
<p><b>powersave -f</b></p>
<p>
           Makes the powersave daemon set the CPUs to the highest supported frequency.
</p>
<p><b>HUGETLB_MORECORE</b></p>
<p>
           Setting this to yes instructs libhugetlbfs to override libc's normal morecore() function with a hugepage version and use it for malloc().
</p>
]]>
</platform_settings>

</flagsdescription>
