Some users are liars, cheaters or at best they don’t fully understand what they are doing. Luckily only a small part of a cluster’s users behaves this way but they can adversely affect the work of the other users who play by the rules.
The type of jobs executed in the LSI cluster are so diverse: commercial software like Matlab, Maple and CPLEX, proprietary software programmed in C, Java, Python,… Currently our policy states that a user may reserve as many slots as real cores need to complete its work. As a result we have a 1:1 slot-cpu ratio.
The execution of single process/single threaded jobs is not a problem: they request one slot and consume one core. However in processes with some level of parallelism, sometimes hidden for a regular user (some Matlab libraries are parallel, Java use threads, …), the core usage does not correspond to the amount of requested slots.
Furthermore, we can set load limits to prevent overloading nodes, but this does not solve the problem and we don’t avoid the possible collapse of the node. On the other hand load limits neither prevents honest users to be penalized.
Using the core binding technique, the CPU affinity mechanism implemented in all the forks of Grid Engine, we can force jobs to use exactly as many cores as reserved slots. Jobs’ processes will remain confined in their assigned cores.
Thus we get a dual goal. We solve the problem with the execution of parallel processes (accounting, overloading, cheating), and we improve the execution time of many processes due to the core confinement avoiding system context switch.
