By default, when scheduling a parallel job, the number of slots allocated on each host will not exceed the number of CPUs on that host even though host MXJ is set greater than number of CPUs. When submitting a parallel job, you can also specify a minimum number and a maximum number of tasks.
If you specify a maximum and minimum number of tasks, the job can start if the minimum number of processors are available, but it always tries to use up to the maximum number of processors, depending on how many processors are available at the time. Once the job starts running, no more processors are allocated to it even though more may be available later on.
Jobs that request fewer tasks than the minimum TASKLIMIT defined for the queue or application profile to which the job is submitted, or more tasks than the maximum TASKLIMIT are rejected. If the job requests minimum and maximum tasks, the maximum requested cannot be less than the minimum TASKLIMIT, and the minimum requested cannot be more than the maximum TASKLIMIT.
If PARALLEL_SCHED_BY_SLOT=Y in lsb.params, the job specifies a maximum and minimum number of job slots instead of tasks. LSF ignores the number of CPUs constraint during parallel job scheduling and only schedules based on slots.
If PARALLEL_SCHED_BY_SLOT is not defined for a resizable job, individual allocation requests are constrained by the number of CPUs during scheduling. However, the final resizable job allocation may not agree. For example, if an autoresizable job requests 1 to 4 tasks, on a 2 CPU, 4 slot box, an autoresizable job eventually will use up to 4 slots.
bsub -n min_task[,max_task]
bsub -n 4,16 myjob
At most, 16 processors can be allocated to this job. If there are less than 16 processors eligible to run the job, this job can still be started as long as the number of eligible processors is greater than or equal to 4.