Add comment that the order does actually matter here to avoid
breaking it in the future.

Removed:
- select_{g,p}_update_basil
- select_{g,p}_ba_init
- select_{g,p}_ba_get_dims

Brian approved

Brian approved

Brian approved

This is only to quite coverity.  I don't think this is a real problem.

Brian approved.

Fix coverity 187747

(i.e. gres=gpu/tesla) it would get a count of 0.

Bug 5570

Note that pipe2() is Linux-specific, but this whole cgroup plugin is
already Linux-specific in design, and the eventfd() call itself is
Linux-specific as well.

Bug 5570.

Didn't realize centos 6 was so far behind.

Bug5503

"IN" tres_usage is reads
"OUT" tres_usage is writes

page faults are only "ins"

In 18.08 the jobacct_info stats were changed to tres_usage arrays which
are init'ed to INFINITE64 but < 18.08 it was init'ed to 0's.

Bug 5554

In 18.08, usage values are stored as bytes but in <18.08 values were
stored in KB, MB, etc.

Also handle cputime adjustments. Related commit: efc161ef.

In 18.08, VMSIZE is stored as bytes and not kilos anymore.

Related commit: c9448c80

Since cputime isn't stored a double anymore, but as a uin64_t, the
cputime is adjusted so that precision isn't lost.

Related commit: efc161ef

In 18.08, the stats are stored in TRES arrays and uses the
slurmdb_find_tres_count_in_string() function to return the TRES value.
If a value doesn't exist, the function returns INFINITE64. But < 18.08
is expecting NO_VAL values.

e.g.
A TRES position of INFINTE caused a lappy0 node to be shown -- I don't
have a lappy0.
brian@lappy:~/slurm/master/lappy$ sacct -j 232809 -o MaxVMSizeNode
 MaxVMSizeNode
--------------

        lappy0

In 18.08, the usage is stored in a TRES arrays and uses the
slurmdb_find_tres_count_in_string() function to return the TRES value.
If a value doesn't exist, the function returns INFINITE64. But < 18.08
is expecting NO_VAL values.

Turns out if you don't close up everything you open the hdf5 lib doesn't
like that.