Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk> writes: > Hi Bjørn-Helge,
Hello, Ole! :) > On 6/23/22 09:18, Bjørn-Helge Mevik wrote: > >> Slurm the same internal variables are used for fairshare calculations as >> for GrpTRESMins (and similar), so when fair share priorities are in use, >> slurm will reduce accumulated GrpTRESMins over time. This means that it >> is impossible(*) to use GrpTRESMins limits and fairshare >> priorities at the same time. > > This is a surprising observation! I discovered it quite a few years ago, when we wanted to use Slurm to enforce cpu hour quota limits (instead of using Maui+Gold). Can't remember anymore if I was surprised or just sad. :D > We use a 14 days HalfLife in slurm.conf: > PriorityDecayHalfLife=14-0 > > Since our longest running jobs can run only 7 days, maybe our limits > never get reduced as you describe? The accumulated usage is reduced every 5 minutes (by default; see PriorityCalcPeriod). The reduction is done by multiplying the accumulated usage by a number slightly less than 1. The number is chosen so that the accumulated usage is reduced to 50 % after PriorityDecayHalfLife (given that you don't run anything more in between, of course). With a halflife of 14 days and the default calc period, that number is very close to 1 (0.9998281 if my calculations are correct :). Note: I read all about these details on the schedmd web pages some years ago. I cannot find them again (the parts about the multiplication with a number smaller than 1 to get the half life), so I might be wrong on some of the details. > BTW, I've written a handy script for displaying user limits in a > readable format: > https://github.com/OleHolmNielsen/Slurm_tools/tree/master/showuserlimits Nice! -- B/H
signature.asc
Description: PGP signature
