Yes, I agree. However, as I pointed out in my previous emails the whole exercise is not to restrict the nodes but to order them. If everything is equal submitting jobs to idling nodes first make much more sense than to busy ones even if busy means only I/O operations (by the way, it is my experience that even I/O operations slow down the mpi calculations). It will be then user's choice when looking at the CPU load of the system to decide how many processors she should request for her job.
Best Regards On Wed, Mar 22, 2017 at 5:10 AM, Christopher Samuel <sam...@unimelb.edu.au> wrote: > > On 22/03/17 08:35, kesim wrote: > > > You are right. Many thanks for correcting. > > Just note that load average is not necessarily the same as CPU load. > > If you have tasks blocked for I/O they will contribute to load average > but will not be using much CPU at all. > > So, for instance, on one of our compute nodes a Slurm job can ask for 1 > core, start 100 tasks doing heavy I/O, they all use the same 1 core and > get the load average to 100 but the other 31 cores on the node are idle > and can quite safely be used for HPC work. > > The manual page for "uptime" on RHEL7 describes it thus: > > # System load averages is the average number of processes that > # are either in a runnable or uninterruptable state. A process > # in a runnable state is either using the CPU or waiting to use > # the CPU. A process in uninterruptable state is waiting for > # some I/O access, eg waiting for disk. > > All the best, > Chris > -- > Christopher Samuel Senior Systems Administrator > Melbourne Bioinformatics - The University of Melbourne > Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545 >
