Differences

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

--- wiki:using_hyperthreading_on_nodes [2014/05/15 00:07] – [Adapting an existing resource setup] neyron
+++ wiki:using_hyperthreading_on_nodes [2015/07/05 10:09] – neyron
@@ Line 1: / Line 1: @@
-====== On using hyper-threads as the leaf level of resources ======
+====== On using (hyper)threads as the leafs of the resources tree======
-Once HyperThreading is enabled at BIOS level, using threads as the leaf level of OAR resources is actually quite strait forward.
+If HyperThreading is enabled in BIOS, using threads as the leafs of OAR (implicit) resources tree is quite simple.
 ===== Using the oar_resource_init script =====
-The last version of the ''oar_resource_init'' script comes with the ''-H'' and ''-T'' options. This allows for generating the ''oarnodesetting'' commands with the ''thread'' properties.
+The last version of the ''oar_resource_init'' script comes with the ''-H'' and ''-T'' options. It generates the ''oarnodesetting'' commands with the ''thread'' properties.
 ===== Adapting an existing resource setup =====
-Here we consider an existing resource setup to which one would like to had the thread leaf resources.
+Here we consider an existing resource setup to which one would like to had the thread as leaf resources.
 First you need to define the thread property:
@@ Line 14: / Line 14: @@
 </code>
-Assuming your cluster is homogeneous, and that resources were consistently created (i.e. the ids of the properties of the resources are well set), you can just add to every resource lines the property: ''thread = (2 * core - 1)'' (''oarnodesetting -s''), and then for each of them create a new resources (''oarnodesetting -a'') with exactly the same values for all properties, except ''thread = (2 * core)'' and ''cpuset = (original cpuset value + # cores per cpu)'' (using ''hwloc'' in a job afterward to verify the correct cpuset settings could be a good idea).
+Assuming your cluster is homogeneous, and that resources were consistently created (i.e. the ids of the properties of the resources are well set), you can add to every resource lines the property: ''thread = (2 * core - 1)'' (''oarnodesetting -p ... ''), and then for each of them create a new resources (''oarnodesetting -a ...'') with exactly the same values for all properties, except ''thread = (2 * core)'' and ''cpuset = (original cpuset value + # cores per cpu)'' (using ''hwloc'' in a job afterward to verify the correct cpuset settings could be a good idea).
 Of course, any shell scripting language will be your friend.
@@ Line 29: / Line 29: @@
 ====== On offlining/onlining hyper-threads with OAR ======
-In this case, cores are the leaf resources (no hyper-thread resource property in OAR resources table), but we would like to enable users to possibly get the 2 hyper-threads associated to each core it in their job.
+In this case, cores are the leaf resources (no thread resource property in OAR resources table), but we would like to enable users to possibly get the 2 hyper-threads associated to each core it in their job.
 It's indeed easy to disable a 2nd thread for a core (see /sys/device/system/cpu), but once this 2nd thread is disabled, it's not so easy to find its number again if we did not keep the information somewhere.
@@ Line 42: / Line 42: @@
  --- //[[pierre.neyron@imag.fr|Pierre Neyron]] 2014/02/21 12:47//