<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">On 12/08/2017 09:54 AM, Mike Cammilleri

      wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:BN6PR06MB3283770FFB1B8EA2FC0BBF2AFB300@BN6PR06MB3283.namprd06.prod.outlook.com">

      <pre wrap="">Hi,

We have allowed some courses to use our slurm cluster for teaching purposes, which of course leads to all kinds of exciting experiments - not always the most clever programming but it certainly teaches me where we need tighten up configurations.

The default method of thinking for many students just starting out is to grab as much CPU as possible - not fully understanding cluster computing and batch scheduling. One example I see often is students using the R parallel package and calling detectCores(), which of course is returning all the cores linux reports. They also did not specify --ntasks, so slurm assigns 1 of course - but there is no check on the ballooning of R processes created with detectCores() and then whatever they're doing with that number. Now we have overloaded nodes.

I see that availableCores() is suggested as a more friendly method for shared resources like this, where it would return the number of cores that were assigned via SLURM. Therefore, a student using the parallel package would need to explicitly specify the number of cores in their submit file. This would be nice IF students voluntarily used availableCores() instead of detectCores(), but we know that's not really enforceable.

I thought cgroups (which we are using) would prevent some of this behavior on the nodes (we are constraining CPU and RAM) -I'd like there to be no I/O wait times if possible. I would like it if either linux or slurm could constrain a job from grabbing more cores than assigned at submit time. Is there something else I should be configuring to safeguard against this behavior? If SLURM assigns 1 cpu to the task then no matter what craziness is in the code, 1 is all they're getting. Possible?

Thanks for any insight!

--mike

</pre>

    </blockquote>

    <p>Sounds like you are looking for CPU affinity.  We use the feature

      to limit jobs to the number of cores they request.  The job can

      see the other cores (e.g. by looking at /proc/cpuinfo) but if they

      try to use them their processes will not get scheduled on any but

      the cores assigned to the job.</p>

    <p># cat /etc/slurm/slurm.conf<br>

      ...<br>

      TaskPlugin=task/cgroup,task/affinity<br>

      TaskPluginParam=sched,autobind=cores</p>

    <p># cat /etc/slurm/cgroup.conf<br>

      CgroupAutomount=yes<br>

      ConstrainCores=yes</p>

    <p>$ taskset -c -p $$ # within a job requesting 4 cores on a node

      with 28<br>

      pid 29247's current affinity list: 15,17,19,21<br>

    </p>

    <div class="moz-signature">-- <tt><br>

        Jeff White<br>

        HPC Systems Engineer - ITS<br>

        Question about or help with Kamiak? Please submit a <a

          href="https://hpc.wsu.edu/support/service-requests/">Service

          Request</a>.</tt>

    </div>

  </body>

</html>