Replies: 2 comments
-
Currently, we do not have any plan since we need to consider the place where we can store the used capacities based on time. I think that we need to investigate metadata storing places. |
Beta Was this translation helpful? Give feedback.
-
That's right, no concrete plans yet. We are aware of the slurm capabilities, and one step towards supporting time dimension was #3125 - analog of "-t" in slurm, but for now it only allows to control the execution time, it is not considered for scheduling. |
Beta Was this translation helpful? Give feedback.
-
The fair sharing algorithm described here https://kueue.sigs.k8s.io/docs/concepts/preemption/#fair-sharing for Kueue seems to be using instantaneous usage to decide on the ClusterQueue share value. Differently than Kueue, the Slurm scheduler has a concept of time and would use decay to factor in past usage as well. For instance, if a ClusterQueue used twice its quota for a long time up until an hour back, but is now at or under quota, then Kueue will simply forget completely about the fact that it used significantly more capacity than allocated in the recent past. Slurm, on the other hand, has a configurable decay to factor in recent usage.
Are there any plans in extending Kueue to support time decay in computing resource usage when considering fair sharing?
Beta Was this translation helpful? Give feedback.
All reactions