LSF Version 7.3 - Using Platform LSF HPC

About SGI cpusets
An SGI cpuset is a named set of CPUs. The processes attached to a cpuset can only run
on the CPUs belonging to that cpuset.
Jobs are attached to a cpuset dynamically created by LSF. The cpuset is deleted when the
job finishes or exits. If not specified, the default cpuset type is dynamic.
Jobs are attached to a static cpuset specified by users at job submission. This cpuset is
not deleted when the job finishes or exits. Specifying a cpuset name at job submission
implies that the cpuset type is static. If the static cpuset does not exist, the job will remain
pending until LSF detects a static cpuset with the specified name.
System architecture
How LSF uses cpusets
On systems running IRIX 6.5.24 and up or SGI Altix ProPack 3.0 and up, cpusets can
be created and deallocated dynamically out of available machine resources. Not only
does the cpuset provide containment, so that a job requiring a specific number of CPUs
will only run on those CPUs, but also reservation, so that the required number of CPUs
are guaranteed to be available only for the job they are allocated to.
LSF can be configured to make use of SGI cpusets to enforce processor limits for LSF
jobs. When a job is submitted, LSF creates a cpuset and attaches it to the job when the
job is scheduled. After the job finishes, LSF deallocates the cpuset. If no host meets the
CPU requirements, the job remains pending until processors become available to
allocate the cpuset.
Assumptions and limitations
◆ When LSF selects cpuset jobs to preempt, MINI_JOB and LEAST_RUN_TIME
are ignored in the PREEMPT_FOR parameter in
lsb.params
◆ Preemptable queue preference is not supported
◆ Before upgrading from a previous version, clusters must be drained of all running
jobs (especially cpuset hosts)
LSF
commands
Master Host
mbatchd
mbschd
schmod_cpuset.so
cpuset hosts
sbatchd
job control
RLA
resource
control
job
job cpuset
bind