Ticket 6734 - Affinity based on GRES for non-GRES jobs
Summary: Affinity based on GRES for non-GRES jobs
Status: OPEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: GPU (show other tickets)
Version: 19.05.x
Hardware: Linux Linux
: 5 - Enhancement
Assignee: Unassigned Developer
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2019-03-21 10:48 MDT by Albert Gil
Modified: 2019-03-21 15:30 MDT (History)
1 user (show)

See Also:
Site: NYU
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed:
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this ticket.
Description Albert Gil 2019-03-21 10:48:29 MDT 
I'm creating this enhanecment from bug 6693 where NYU was asking for the following enhancement.

The need a way to ensure or encourage as much as possible that jobs that are not asking for a GRES but are allocated to a node with some GRES with CPUs assigned in the gres.conf are not bind to those CPUs but to "free CPUs" (CPUs not specified in the gres.conf).

An initial idea could be adding some new option(s) to current  --gres-flags or --distribution to add this bindig logic: "not use or try to avoid GRES-assigned CPUs for jobs not asking for that GRES".
Comment 1 Moe Jette 2019-03-21 10:57:32 MDT 
cons_tres does not have anything like this today, but perhaps the cores could be assigned a weight similar to the node weight. Cores associated with more GRES types (and systems could possibly have many GRES types with various bindings) could have a higher weight and be avoided when possible. That would be a fairly major effort and is unlikely to happen soon.