Rules

Follow these guidelines when you specify first execution host candidates:

  • If you specify a host group or compute unit, you must first define the host group or compute unit in the file lsb.hosts.
  • Do not specify a dynamic host group as a first execution host.
  • Do not specify all, allremote, others, or a host partition as a first execution host.
  • Do not specify a preference (+) for a host identified by (!) as a first execution host candidate.
  • For each parallel job, specify enough regular hosts to satisfy the CPU requirement for the job. Once LSF selects a first execution host for the current job, the other first execution host candidates become unavailable to the current job.

  • You cannot specify first execution host candidates when you use the brun command.

If the first execution host is incorrect at job submission, the job is rejected. If incorrect configurations exist on the queue level, warning messages are logged and displayed when LSF starts, restarts, or is reconfigured.

Job chunking

Specifying first execution host candidates affects job chunking. For example, the following jobs have different job requirements, and are not placed in the same job chunk:
bsub -n 2 -m "hostA! hostB hostC" myjob
bsub -n 2 -m "hostA hostB hostC" myjob
bsub -n 2 -m "hostA hostB! hostC" myjob
The requirements of each job in this example are:
  • Job 1 must start on hostA
  • Job 2 can start and run on hostA, hostB, or hostC
  • Job 3 must start on hostB

For job chunking, all jobs must request the same hosts and the same first execution hosts (if specified). Jobs that specify a host preference must all specify the same preference.

Resource reservation

If you specify first execution host candidates at the job or queue level, LSF tries to reserve a job slot on the first execution host. If LSF cannot reserve a first execution host job slot, it does not reserve slots on any other hosts.

Compute units

If compute units resource requirements are used, the compute unit containing the first execution host is given priority:

bsub -n 64 -m "hg! cu1 cu2 cu3 cu4" -R "cu[pref=config]" myjob

In this example the first execution host is selected from the host group hg. Next, in the job’s allocation list are any appropriate hosts from the same compute unit as the first execution host. Finally, remaining hosts are grouped by compute unit, with compute unit groups appearing in the same order as in the ComputeUnit section of lsb.hosts.

Compound resource requirements

If compound resource requirements are being used, the resource requirements specific to the first execution host should appear first:

bsub -m "hostA! hg12" -R "1*{select[type==X86_64]rusage[licA=1]} + {select[type==any]}" myjob

In this example the first execution host must satisfy: select[type==X86_64]rusage[licA=1]