Ticket 4677 - Accounting on slurmd: use 1min LoadAvg instead of 5min.
Summary: Accounting on slurmd: use 1min LoadAvg instead of 5min.
Status: OPEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: Accounting (show other tickets)
Version: 17.02.9
Hardware: Linux Linux
: 5 - Enhancement
Assignee: Unassigned Developer
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2018-01-24 09:42 MST by Chrysovalantis Paschoulas
Modified: 2021-10-13 05:10 MDT (History)
0 users

See Also:
Site: Jülich
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
NoveTech Sites: ---
Nvidia HWinf-CS Sites: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Tzag Elita Sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed:
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---


Attachments
Patch file for 1min load avg on slurmd - version 17.02.9-1 (854 bytes, patch)
2018-01-24 09:42 MST, Chrysovalantis Paschoulas
Details | Diff

Note You need to log in before you can comment on or make changes to this ticket.
Description Chrysovalantis Paschoulas 2018-01-24 09:42:49 MST
Created attachment 6009 [details]
Patch file for 1min load avg on slurmd - version 17.02.9-1

Some users and admins on our site think it makes more sense to change how slurmd is doing accounting about system load and use the 1min LoadAvg instead of the 5min one.

It makes more sense to them because when a job starts the 5min load avg is affected from the previous job on the node.

Attached you can find a proposed patch for Slurm 17.02.09.
Comment 1 Brian Christiansen 2018-01-24 16:17:48 MST
Thanks for the contribution and suggestion. We don't feel comfortable making the a blanket change from the 5min to 1min average. We would feel more comfortable making it configurable. We're thinking of something like a SlurmdParameters=load_avg={1|5|15} option in the slurm.conf. SlurmdParameters would be similar to how SchedulerParameters is coded.

How do you feel about this? If you can provide a patch with this we can work on getting it into the code.

Thanks,
Brian
Comment 2 Chrysovalantis Paschoulas 2018-01-25 02:36:07 MST
Actually I was thinking to ask you for such parameter but then I said no it's more work to do so let's stay in our basic requirement...

So, in short, that's great!

I totally agree with your solution! No need to provide me the patch, we will use the next minor release of 17.02 (please backport it there).

Thank you!
Comment 3 Chrysovalantis Paschoulas 2018-01-25 07:16:27 MST
Actually, we are really fine if there is no plan for your side to release 17.02.10.

We will use 17.11.x at some point later in the future so no need to backport this feature to 17.02 just for us.
Comment 4 Tim Wickberg 2018-01-25 17:59:19 MST
(In reply to Brian Christiansen from comment #1)
> How do you feel about this? If you can provide a patch with this we can work
> on getting it into the code.

Just to clarify here: Brian is not committing us to providing this. He was only asking if you'd be interested in submitting a patch that covers this.

(In reply to Chrysovalantis Paschoulas from comment #3)
> We will use 17.11.x at some point later in the future so no need to backport
> this feature to 17.02 just for us.

New functionality not permitted on the stable releases; this should be developed against the master branch (which will become the 18.08 release).
Comment 5 Chrysovalantis Paschoulas 2018-02-05 03:25:43 MST
(In reply to Tim Wickberg from comment #4)
> (In reply to Brian Christiansen from comment #1)
> > How do you feel about this? If you can provide a patch with this we can work
> > on getting it into the code.
> 
> Just to clarify here: Brian is not committing us to providing this. He was
> only asking if you'd be interested in submitting a patch that covers this.
> 
> (In reply to Chrysovalantis Paschoulas from comment #3)
> > We will use 17.11.x at some point later in the future so no need to backport
> > this feature to 17.02 just for us.
> 
> New functionality not permitted on the stable releases; this should be
> developed against the master branch (which will become the 18.08 release).

Yeah, thanks for the clarification ;)

In my mind I wrongly thought that this was not affecting any protocol (only slurmd reading the config file and done!) and I completely ignored the policy that new functionality is not permitted on the stable releases but only on master branch for future releases.. :P

Cheers,
Valantis
Comment 6 Chrysovalantis Paschoulas 2021-10-13 05:10:03 MDT
Hi!

Any news on this one?

This seems easy to be implemented, so I guess the prio was very low for it..

Any plans to implement it in newer Slurm versions?