LSF Version 7.3 - Administering Platform LSF

Tuning LSF for Large Clusters
620 Administering Platform LSF
Run badmin reconfig to create and use the subdirectories.
Duplicate event
logging
NOTE: If you enabled duplicate event logging, you must run badmin mbdrestart instead of
badming reconfig to restart mbatchd.
Run bparams -l to display the value of the MAX_INFO_DIRS parameter.
Example MAX_INFO_DIRS=10
mbatchd
creates ten subdirectories from
LSB_SHAREDIR/cluster_name/logdir/info/0 to
LSB_SHAREDIR/cluster_name/logdir/info/9.
Processor binding for LSF job processes
Rapid progress of modern processor manufacture technologies has enabled the low
cost deployment of LSF on hosts with multicore and multithread processors. The
default soft affinity policy enforced by the operating system scheduler may not give
optimal job performance. For example, the operating system scheduler may place
all job processes on the same processor or core leading to poor performance.
Frequently switching processes as the operating system schedules and reschedules
work between cores can cause cache invalidations and cache miss rates to grow
large.
Processor binding for LSF job processes takes advantage of the power of multiple
processors and multiple cores to provide hard processor binding functionality for
sequential LSF jobs.
RESTRICTION: Processor binding is supported on hosts running Linux with kernel version 2.6 or
higher.
For parallel jobs, LSF binds the job at the first execution host, not other remote
hosts. LSF does not bind remote tasks for parallel jobs because parallel jobs typically
exclusively allocate entire nodes to a job.
When processor binding for LSF job processes is enabled on supported hosts, job
processes of an LSF job are bound to a processor according to the binding policy of
the host. When an LSF job is completed (exited or done successfully) or suspended,
the corresponding processes are unbound from the processor.
When a suspended LSF job is resumed, the corresponding processes are bound
again to a processor. The process is not guaranteed to be bound to the same
processor it was bound to before the job was suspended.
The processor binding affects the whole job process group. All job processes forked
from the root job process (the job RES) are bound to the same processor.
Processor binding for LSF job processes does not bind daemon processes.
If processor binding is enabled, but the execution hosts do not support processor
affinity, the configuration has no effect on the running processes. Processor
binding has no effect on a single-processor host.