SLURM - Revision history

GiulioFontana: /* How to maximise the priority of your jobs */

2026-07-20T14:05:55Z

How to maximise the priority of your jobs

← Older revision		Revision as of 14:05, 20 July 2026
Line 311:		Line 311:

	; Only request CPUs and RAM that your job really needs		; Only request CPUs and RAM that your job really needs
	:: Usually, code exploits multiple CPUs only if designed to do so: if unsure, only ask for 1 CPU		:: Usually, code exploits multiple CPUs only if specifically designed to do so: if unsure, only ask for 1 CPU
	:: The fewer resources your job asks for, the less it will wait before they become available		:: The fewer resources your job asks for, the less it will wait before they become available
	:: Asking for fewer CPUs and/or less RAM improves your FairShare		:: Asking for fewer CPUs and/or less RAM improves your FairShare

GiulioFontana: /* How FairShare works */

2026-07-20T14:03:59Z

How FairShare works

← Older revision		Revision as of 14:03, 20 July 2026
Line 295:		Line 295:
	#* '''RAM''' - impact on FairShare is proportional to the amount of RAM used		#* '''RAM''' - impact on FairShare is proportional to the amount of RAM used
	#* '''GPUs''' - impact on FairShare is proportional to the number of GPUs used		#* '''GPUs''' - impact on FairShare is proportional to the number of GPUs used
	#** 40 GB GPUs have double the impact on FairShare than 20 GB GPUs		#** note: 40 GB GPUs have double the impact on FairShare than 20 GB GPUs
	# The impact on FairShare of any use of resources is '''proportional to its duration'''		# The impact on FairShare of any use of resources is '''proportional to its duration'''
	#* example: using 32 GB of RAM for 48h has the same impact of using 64 GB of RAM for 24h		#* example: using 32 GB of RAM for 48h has the same impact of using 64 GB of RAM for 24h

GiulioFontana: /* research users and students users */

2026-07-20T13:59:29Z

research users and students users

← Older revision		Revision as of 13:59, 20 July 2026
Line 187:		Line 187:
	= <code>research</code> users and <code>students</code> users =		= <code>research</code> users and <code>students</code> users =

	Users of Mufasa belong to two '''user categories'''. Categories provide users with different access to to Mufasa's resources: the idea being to provide researchers with more access while still letting students ~~use~~ the server.		Users of Mufasa belong to two '''user categories'''. Categories provide users with different access to to Mufasa's resources: the idea being to provide researchers with more access while still letting students benefit from the server's capabilities.

	User categories in Mufasa are the following:		User categories in Mufasa are the following:

GiulioFontana: /* SLURM Quality of Service (QOS) */

2026-07-20T13:57:17Z

SLURM Quality of Service (QOS)

← Older revision		Revision as of 13:57, 20 July 2026
Line 169:		Line 169:
	\|}		\|}

	A key piece of information in the table above is the '''priority tier''' associated to each QOS.		A key piece of information in the table above is the '''priority tier''' associated to each QOS. In Mufasa 2.0, priority tiers are used to encourage users to use the '''least powerful QOS that is compatible with their needs''', where "powerful" means "rich with resources". Less powerful QOSes increase the priority of the jobs that use them, so these jobs tend to be executed sooner. See [[#Job priority\|Job priority]] for details about how priority affects the execution order of jobs in Mufasa 2.0.

	In Mufasa 2.0, priority tiers are used to encourage users to use the '''least powerful QOS that is compatible with their needs''', where "powerful" means "rich with resources". Less powerful QOSes increase the priority of the jobs that use them, so these jobs tend to be executed sooner. See [[#Job priority\|Job priority]] for details about how priority affects the execution order of jobs in Mufasa 2.0.

	== The <code>build</code> QOS ==		== The <code>build</code> QOS ==

GiulioFontana: /* SLURM Quality of Service (QOS) */

2026-07-20T13:55:34Z

SLURM Quality of Service (QOS)

← Older revision		Revision as of 13:55, 20 July 2026
Line 94:		Line 94:
	! max # of</br>CPUs		! max # of</br>CPUs
	! max RAM</br>[GB]		! max RAM</br>[GB]
	! max ~~(min)~~ # of</br>3g.20GB</br>GPUs		! max # of</br>3g.20GB</br>GPUs
	! max ~~(min)~~ # of</br>4g.20GB</br>GPUs		! max # of</br>4g.20GB</br>GPUs
	! max ~~(min)~~ # of</br>40GB</br>GPUs		! max # of</br>40GB</br>GPUs
	\|-		\|-
	! rowspan="1" style="text-align:center;" \| build		! rowspan="1" style="text-align:center;" \| build

GiulioFontana: /* SLURM Quality of Service (QOS) */

2026-07-20T13:52:48Z

SLURM Quality of Service (QOS)

← Older revision		Revision as of 13:52, 20 July 2026
Line 94:		Line 94:
	! max # of</br>CPUs		! max # of</br>CPUs
	! max RAM</br>[GB]		! max RAM</br>[GB]
	! max # of</br>3g.20GB</br>GPUs		! max (min) # of</br>3g.20GB</br>GPUs
	! max # of</br>4g.20GB</br>GPUs		! max (min) # of</br>4g.20GB</br>GPUs
	! max # of</br>40GB</br>GPUs		! max (min) # of</br>40GB</br>GPUs
	~~! MinTRES</br>(GPUs)~~
	\|-		\|-
	! rowspan="1" style="text-align:center;" \| build		! rowspan="1" style="text-align:center;" \| build
Line 105:		Line 104:
	\| 2		\| 2
	\| 16		\| 16
	~~\| -~~
	\| -		\| -
	\| -		\| -
Line 116:		Line 114:
	\| 2		\| 2
	\| 64		\| 64
	\| 1		\| 1 (min=1)
	\| -		\| -
	\| -		\| -
	~~\| one 3g.20GB~~
	\|-		\|-
	! rowspan="1" style="text-align:center;" \| nogpu		! rowspan="1" style="text-align:center;" \| nogpu
Line 127:		Line 124:
	\| 16		\| 16
	\| 128		\| 128
	~~\| -~~
	\| -		\| -
	\| -		\| -
Line 138:		Line 134:
	\| 8		\| 8
	\| 64		\| 64
	\| 1		\| 1 (min=1)
	\| -		\| -
	\| -		\| -
	~~\| one 3g.20GB~~
	\|-		\|-
	! rowspan="1" style="text-align:center;" \| gpuwide		! rowspan="1" style="text-align:center;" \| gpuwide
Line 150:		Line 145:
	\| 64		\| 64
	\| -		\| -
	\| 1		\| 1 (min=1)
	\| -		\| -
	~~\| one 4g.20GB~~
	\|-		\|-
	! rowspan="1" style="text-align:center;" \| gpuheavy-20		! rowspan="1" style="text-align:center;" \| gpuheavy-20
Line 161:		Line 155:
	\| 128		\| 128
	\| -		\| -
	\| 2		\| 2 (min=1)
	\| -		\| -
	~~\| one 4g.20GB~~
	\|-		\|-
	! rowspan="1" style="text-align:center;" \| gpuheavy-40		! rowspan="1" style="text-align:center;" \| gpuheavy-40
Line 173:		Line 166:
	\| -		\| -
	\| -		\| -
	\| 1		\| 1 (min=1)
	~~\| one 40GB~~
	\|}		\|}

GiulioFontana: /* SLURM Quality of Service (QOS) */

2026-07-20T13:45:58Z

SLURM Quality of Service (QOS)

← Older revision		Revision as of 13:45, 20 July 2026
Line 37:		Line 37:
	</pre>		</pre>

	which provides an output similar to the following:		which provides an output similar to the following (see below for the same data in table form):

	<pre style="color: lightgrey; background: black;">		<pre style="color: lightgrey; background: black;">

GiulioFontana: /* How to maximise the priority of your jobs */

2026-05-26T11:36:12Z

How to maximise the priority of your jobs

← Older revision		Revision as of 11:36, 26 May 2026
Line 329:		Line 329:
	:: Asking for less of Mufasa's time improves your FairShare		:: Asking for less of Mufasa's time improves your FairShare

	; ~~Test~~ and ~~debug your~~ code using less powerful QOSes before running it on more powerful QOSes		; Debug and test code using less powerful QOSes before running it with more powerful QOSes
	:: Your test jobs will get a higher priority and your FairShare will improve		:: Your test jobs will get a higher priority and your FairShare will improve

GiulioFontana: /* How to maximise the priority of your jobs */

2026-05-26T11:35:02Z

How to maximise the priority of your jobs

← Older revision		Revision as of 11:35, 26 May 2026
Line 332:		Line 332:
	:: Your test jobs will get a higher priority and your FairShare will improve		:: Your test jobs will get a higher priority and your FairShare will improve

	; Cancel jobs ~~when~~ you don't need them anymore		; Cancel jobs that you don't need them anymore
	:: ~~Use~~ [[User_Jobs#Cancelling_a_job_with_scancel\|scancel]] to delete ~~your jobs when finished~~ (or if crashed ~~due to a bug~~): your Fairshare will improve		:: Always use [[User_Jobs#Cancelling_a_job_with_scancel\|scancel]] to delete completed (or crashed) jobs: your Fairshare will improve
	\|}		\|}

GiulioFontana: /* How to maximise the priority of your jobs */

2026-05-26T11:33:06Z

How to maximise the priority of your jobs

← Older revision		Revision as of 11:33, 26 May 2026
Line 323:		Line 323:
	:: Usually, code exploits multiple CPUs only if designed to do so: if unsure, only ask for 1 CPU		:: Usually, code exploits multiple CPUs only if designed to do so: if unsure, only ask for 1 CPU
	:: The fewer resources your job asks for, the less it will wait before they become available		:: The fewer resources your job asks for, the less it will wait before they become available
	:: Asking for fewer CPUs and/or less RAM improves your FairShare ~~--> priority of your future jobs~~		:: Asking for fewer CPUs and/or less RAM improves your FairShare

	; Do not request more time than your jobs needs to complete		; Do not request more time than your jobs needs to complete
	:: Make a worst-case estimate and only ask for that duration		:: Make a worst-case estimate and only ask for that duration
	:: Asking for less of Mufasa's time improves your FairShare ~~--> priority of your future jobs~~		:: Asking for less of Mufasa's time improves your FairShare

	; Test and debug your code using less powerful QOSes before running it on more powerful QOSes		; Test and debug your code using less powerful QOSes before running it on more powerful QOSes