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



Reply via email to