Fixes an issue where mems available to the cpuset are restricted to the local mems associated with the CPU's in each job's cpuset, when not using NUMA

For example:

Aug 1 14:03:47 c5a-s1 pbs_mom: LOG_INFO::create_job_cpuset, creating cpuset for job 331071.moab.ufhpc: 16 cpus (15-30), 3 mems (1-3)

Indeed, checking /dev/cpuset/torque/331071.moab.ufhpc/mems, we see 1-3.

According to the comment above src/resmom/linux/cpuset.c's create_job_cpuset() function, this should not happen:

* - Without NUMA support, the cpuset will contain
* a subset of the cpus of the TORQUE cpuset, and all
* mems of the TORQUE cpuset.

The intent is easy to understand - add only enough mems to the cpuset to satisfy the request. However, Torque makes no effort to try to keep track of how much of a mem has already been "committed" to other jobs. Even if it did, the strategy is doomed by jobs which need more than one mem (now you are sensitive to numa_zonelist_order, and probably more vagaries).

cpuset and NUMA support have historically been separate config options for a good reason. If cpuset support is enabled, and NUMA support is not, then the only "correct" move Torque has is to set the available mems to tmems. Otherwise, there is just going to be trouble in the form of premature OOMs at customer sites.

Submitted as proxy for Craig Prescott
18685
TRQ-2124