Bug 167 - CPUSET tracking for jobs
: CPUSET tracking for jobs
Status: NEW
Product: TORQUE
: 2.5.x
: PC Linux
: P5 enhancement
Assigned To: David Beer
  Show dependency treegraph
Reported: 2011-12-13 20:48 MST by Craig West
Modified: 2011-12-13 21:40 MST (History)
2 users (show)

See Also:



You need to log in before you can comment on or make changes to this bug.

Description Craig West 2011-12-13 20:48:17 MST
At the moment when a job gets allocated to a node (regardless of cpusets) the
node shows a <#>/<jobid> which queried (e.g. pbsnodes <node>). 

What I would like to propose is that in the case of cpusets that the <#> is
actually the same as the core that was allocated for the cpuset. This would
make tracking jobs easier as we could tell which cpus a job was allocated
without having to search through on the node.

I do see a few issues. Like what happens for people not using cpusets. What
happens for clusters where there are more jobs allocated than there are cpus.
But I think in both those cpusets are not active.

Comment 1 David Beer 2011-12-13 21:17:49 MST
This is currently the case, but in 4.0 this is going to change. The reason for
the change in 4.0 is that we found it better to give core indexes in order of
proximity, which is easy to do with hwloc (used in 4.0). However, in TORQUE 2.5
and 3.0 the index in the exec host or pbsnodes is the index the job gets in the
Comment 2 Craig West 2011-12-13 21:40:07 MST

Thanks for the information. I wasn't actually requiring it in 2.5.x, and as it
would change the output it could cause problems, although I would expect it
I was more interested in having this as a feature in the future, as you have

Note: There is no option for 4.0 or 4.0-Beta when submitting bugs to Torque.