Merge the README.cray-cs file into README.cray. [reviewed by Tom]

Since the set up procedure for a CCS machine and the Cray X-series machines is
so similar, I am merging the two back into a single file.  This includes rolling
over the change to doc/release/platforms/README.cray-cs - instead of having the
user set their CHPL_HOME and CHPL_PATH/MANPATH variables, have them use the
util/setchplenv scripts provided.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21893 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Initial support for the NUMA locale model

[Contributed to and reviewed by Greg and David]

This commit adds initial support for the NUMA locale model.  NUMA
domains can be accessed via Chapel on statements.  A subsequent commit
will implement data parallel iteration over NUMA domains.

High level description:

The NUMA locale model describes a top level locale with 1 or more
sublocales that represent NUMA domains.  Programs can use the on
statements to execute code on both the top level locale as well as the
sublocales.  The top level locale is not a separate compute locale, so
if used in an on statement, the code will run on any one of its
sublocales.  As always, all programs start on Locale[0], a top level
locale.

Details:

The NUMA locale model defines its locale id to be a record of two 32
bit integers: node id (top level id, as has been traditionally used)
and sublocale id (NUMA domain id).  A top level locale has its
sublocale field set to 'any'.

Each top level locale (class LocaleModel) has numSubLocales sublocales
of type class NumaDomain.  The sublocales are numbered 0 to
numSubLocales-1.  Besides initialization details, the NUMA locale
model differs from the flat locale model in its on statement support.
If the target of the on statement is on the same node as the currently
running task, check to see if we are running on the correct sublocale,
and if not, make a tasking layer call to change sublocales (and change
back when we return from the call to the outlined on statement body).

To get the sublocale portion of the locale id, we use a call to
chpl_task_getRequestedSubloc().  This enables us to return the proper
top level locale id (node id + any), even though the task is running
on a specific sublocale.  This has a possibly unexpected side effect
regarding tasks that run on the top level locale and then execute code
on one of its sublocale.  Upon returning to code running on the top
level locale, because its sublocale is 'any', the tasking layer will
not move the task back to the actual sublocale it was running on.
More concretely,

   // executing on Locale[0], physical subloc X
   on (here:LocaleModel).getChild(Y) ... // executing on subloc Y
   // executing on Locale[0], physical subloc Y

It is not difficult to move the task back to its original sublocale,
but it does take a couple of extra tasking layer calls.  The final
behavior is still up for debate and could also be controlled by a
param.

Changes to existing code:

- runtime/include/chpl-gen-includes.h
  modules/internal/ChapelLocale.chpl

  Use chpl_task_getRequestedSubLoc() instead of chpl_task_getSubLoc()

- modules/internal/localeModels/flat/LocaleModel.chpl

  Add boolean param localeModelHasSubLocales (also in numa).  As
  stated in the comments, we should somehow unify this with
  CHPL_LOCALE_MODEL_NUM_SUBLOCALES in the runtime.

Testing status:

The current implementation has been tested with CHPL_TASKS=qthreads,
as it is currently the only tasking layer that supports multiple NUMA
domains.  Of the 52 failing tests, only one is unexplained
(types/tuple/deitz/test_strings_and_tuples gets the wrong answer).
The rest can be categorized as follows:

  - 30 also failing with flat+qthreads
  - 13 need larger stack size (some of the 30 above also do)
  - 4 need skip/.good if due to assuming --no-local/--local compilation
  - 4 differ in memory counts

I also added a few new tests for NUMA specific testing.  These have
.good files that assume 4 NUMA domains.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21894 3a8e244f-b0f2-452b-bcba-4c88e055c3ca