You can use include files in your slurm.conf
(http://slurm.schedmd.com/slurm.conf.html), just have that file be local
on each cluster, I am guessing you already have something like this
since you would need a different cluster name for each system. I would
use jobacct_gather/linux, the cgroup one adds quite a bit of overhead
with little benefit.
On 06/10/15 09:36, Jacqueline Scoggins wrote:
Re: [slurm-dev] Re: cgroup setup and cpuset issues
I also have another question. What will be the impact of these
settings if this is not a single system with one slurm configuration
but multiple clusters with one slurm configuration and some cluster
groups are not going to be using cgroups?
i.e. - Shared resources owned by separate PI's and they have their
own set of policies in regards to the run time environment. Exclusive
resources owned by the IT department that all approved PI's and staff
members can use and they will be controlled by our policies regarding
their run time environment (hence cgroup settings).
ProctrackType=proctrack/cgroup
TaskPlugin=task/cgroup
JobAcctGatherType=jobacct_gather/cgroup
Thanks
Jackie
On Wed, Jun 10, 2015 at 8:26 AM, Peter Kjellstrom <[email protected]
<mailto:[email protected]>> wrote:
What is the user trying to run?
We've seen that, for example, IntelMPI-4.x has major problems setting
up it's pinning in a slurm created cgroup with size less than a full
node. In this case actual pinning is random/corrupt and the only
work-around is to request a whole node.
/Peter K
On Tue, 09 Jun 2015 17:51:20 -0700
Jacqueline Scoggins <[email protected] <mailto:[email protected]>>
wrote:
> First round of testing cgroups and noticed that no matter how many
> cpus requested (-n x) the users job is only running on one cpu.
...
> Thanks in advanced for your assistance.
>
>
> Jackie Scoggins