Differences

This shows you the differences between two versions of the page.

--- wiki:managing_resources_cpu_gpu [2018/10/17 00:41] – [Managing processing unit topologies] neyron
+++ wiki:managing_resources_cpu_gpu [2020/03/03 13:31] – [Managing processing unit topologies] neyron
@@ Line 11: / Line 11: @@
 In database these 4 kinds of resource properties are all stored as **columns** of the ''resources'' table. A rows then gives the set of properties for one resource.
-**Given a hierarchy** (chosen by the administrator for its cluster setup, for instance cluster/switch/host/cpu/core, but thread could be added, or other customizations), one row in the table gives information for the **lowest level of resources of the hierarchy** (e.g. core). Then **groups of lines** define higher levels, like Russian dolls (e.g. ''#C'' rows for CPUs, ''#H*#C'' rows for hosts, ...).
+**Given a hierarchy** (chosen by the administrator for his cluster setup, for instance cluster/switch/host/cpu/core, but thread could be added, or other customizations), one row in the table gives information for the **lowest level of resources of the hierarchy** (e.g. core). Then **groups of lines** define higher levels, like Russian dolls (e.g. ''#C'' rows for CPUs, ''#H*#C'' rows for hosts, ...).
 One rule must be kept in mind: **any unique object in the resources hierarchy must have a unique id among its set of object**. For example:
@@ Line 69: / Line 69: @@
 Also, if some nodes do not have any GPU, you could set the value of the property for the corresponding resources to ''gpudevice=-1'', and let the users add to the ''oarsub'' command a ''-p "gpudevice >=0"'' in order to get resources with GPUs.
-===== Second scenario, more complexe =====
+===== Second scenario, more complex =====
 Lets assume now that you have a cluster of 3 nodes with 32 GB of RAM and per node:
   * 2 CPUs of 6 cores each
@@ Line 167: / Line 167: @@
 When reserving 1 GPU, the user obviously gets the 3 cores associated to the GPUs.
+Finally, GPU jobs can be tied to GPU resources (where ''gpu > 0'') with the following admission rule (see ''oaradmissionrules''), so that users don't have to set ''-p "gpu > 0"'' in their command lines:
+<code perl>
+foreach my $mold (@{$ref_resource_list}){
+  foreach my $r (@{$mold->[0]}){
+    my $gpu_request = 0;
+    foreach my $resource (@{$r->{resources}}) {
+      if ($resource->{resource} eq "gpu") {
+        $gpu_request = 1;
+      }
+    }
+    if ($gpu_request) {
+      if ($r->{property} ne ""){
+        $r->{property} = "($r->{property}) AND gpu > 0";
+      }else{
+        $r->{property} = "gpu > 0";
+      }
+      print("[ADMISSION RULE] Tie job resource request for GPU to resources with GPU\n");
+    }
+  }
+}
+</code>
 Warning: make sure to look at lstopo output in order to correctly associate cpuset and gpudevices, e.g. not associating cores and GPUs not attached to a same CPU.